GitLab.org/GitLab: Release v12.2.0-ee
Name: GitLab
Owner: GitLab.org
Release: GitLab 12.2
Released: 2020-04-03
License: MIT
Release Assets:
#### [Ultimate](https://about.gitlab.com/pricing/ultimate/)
##### [Application security testing](https://about.gitlab.com/stages-devops-lifecycle/application_security_testing/)
[Security approval in Merge Requests](https://docs.gitlab.com/ee/user/application_security/#security-approvals-in-merge-requests-ultimate)
> You can now ensure that Merge Requests which introduce new vulnerabilities are not merged unless
> specific people review and approve the change.
>
> This makes it easier for you and your teams to follow your compliance policies and also ensures
> that new vulnerabilities do not unintentionally get introduced into your code base without explicit approval.
[Security Dashboard as default view for groups](https://docs.gitlab.com/ee/user/profile/preferences.html#group-overview-content)
> You can now set the group Security Dashboard as the default screen
> you will see when you view a group. Notably, this is done on a per-user
> basis, meaning everyone in the team can choose the view they are most
> interested in.
>
> This allows security teams and users primarily concerned with the
> security posture of a group to quickly determine security health
> without having to navigate through a menu to find the information.
[Label and annotate issues using GLFM in alerts from external Prometheus instances](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#external-prometheus-instances)
> If you have an externally managed Prometheus instance, we just made it simpler to triage and assign incidents.
> We added a field called `gitlab_incident_markdown` which GitLab looks for on alerts and displays at the top of incidents
> in the **Summary** section. GLFM ([GitLab Flavored Markdown](https://docs.gitlab.com/ee/user/markdown.html#gitlab-flavored-markdown-gfm))
> can be added to your alert configuration files in AlertManager and used to automatically assign and label issues that are opened on alerts.
[Label issues opened by Prometheus alerts with incident](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#taking-action-on-incidents-ultimate)
> When you have configured your project to open issues on Prometheus alerts, the `incident` label
> will now be applied automatically. This enables incident response teams to easily triage incidents
> using issue boards and eliminates manual work required to indicate issues that are incidents and
> those being used for other purposes.
[Restrict group membership by domain](https://docs.gitlab.com/ee/user/group/index.html#allowed-domain-restriction)
> For security-minded organizations, maintaining control over who has access
> to projects and groups is an important aspect of risk management. In 12.2,
> we're adding an additional tool for administrators and group owners to
> ensure that the right people have access; you're now able to restrict
> group membership to only users who are using an email address matching
> a selected domain name.
>
> This means that YourCompany can ensure that users must be using a yourcompany.com
> email address to be allowed into the group, helping prevent owners from
> accidentally adding users outside the organization.
[Percent Rollout Strategy for Feature Flags](https://docs.gitlab.com/ee/operations/feature_flags.html#rollout-strategy)
> You can now select "Percentage Rollout" as a rollout strategy for your feature flags. Percentage Rollout allows percentages to be set individually for each environment and each flag. When Percentage rollout is configured and the flag is enabled, the feature will be shown to the configured percentage of logged-in users. This allows you to do controlled rollouts, monitoring the behavior of the target environment to ensure the results are as expected.
[User ID Rollout Strategy for Feature Flags](https://docs.gitlab.com/ee/operations/feature_flags.html#target-users)
> You can now choose "User ID" as a rollout strategy for your feature flags. The User ID strategy allows you to specify a comma-separated list of User IDs and then toggle a feature flag only for the specified users. This can allow you to target testing features with specific cohorts or segments of your userbase.
[Read and write admin notes for a user via API](https://docs.gitlab.com/ee/api/users.html#for-admins) (self-managed only)
> Writing admin notes for users can be a useful tool for administrating a
> GitLab userbase at scale. On GitLab.com, our admins typically use the `note`
> attribute to keep track of user behavior. At scale, writing these notes
> via the UI quickly becomes challenging to manage. The user API
> can now be used to read and write admin notes, making it easier than ever
> for instance admins to add reminders at the user level.
[Bulk edit issue labels at the group level](https://docs.gitlab.com/ee/user/group/bulk_editing/index.html)
> Users can change the label for many issues at the same time in a specific project. In GitLab 12.2, we are releasing the capability to bulk edit labels for many issues at the group level, allowing for easier management of issue labels.
[Annotations for Designs](https://docs.gitlab.com/ee/user/project/issues/design_management.html)
> Annotations for Designs allow Designers and Developers to more closely collaborate on designs through comments left on specific points in designs. By allowing Designs on issues to support this collaboration we're continuing to enhance the value of Issues as the Single Source of Truth for work inside of GitLab. At the same time we're also providing a structured way to give feedback and have a discussion around Designs.
>
> This is just the beginning of focusing on designer specific workflows inside of GitLab and we'd love for you to contribute to our [strategy](https://about.gitlab.com/direction/plan/design_management/).
>
> Design Management is currently an *alpha* feature and is subject to
> change at any time without prior notice. Design Management requires [Large File Storage (LFS)](https://docs.gitlab.com/ee/topics/git/lfs/index.html)
> to be enabled.
[Cross-project Merge Request Dependencies](https://docs.gitlab.com/ee/user/project/merge_requests/dependencies.html)
> Organizations that ship multiple related products often share common
> services and libraries to prevent the same problem being solved twice.
> These are often stored in their own individual projects, but this makes
> coordinating changes between services and their consumers difficult when
> a feature requires changes to multiple components.
>
> In GitLab 12.2, Cross-project Merge Request Dependencies allow these
> dependency relationships to be defined in GitLab, to prevent changes from
> being merged in the wrong order. It also helps increase the visibility of
> these relationships during code review, helping the reviewer understand
> the full scope of changes.
[Assign groups as code owners](https://docs.gitlab.com/ee/user/project/codeowners/)
> Knowing who should review your changes often isn't obvious. Assigning code owners to files makes this easy. Once assigned, you can see code owners when viewing a file and automatically add them as merge request approvers.
>
> In GitLab 12.2, you can now assign Groups, in addition to a GitLab username and email as code owners. Assigning a group prevents code owners falling out of sync as teams change, particularly when using LDAP to manage group membership.
[Design Management uploads](https://docs.gitlab.com/ee/user/project/issues/design_management.html)
> Designers and Developers can now easily collaborate on design assets
> inside of a GitLab issue with GitLab's Design Management uploads.
> Designs can be uploaded to a new area inside of an issue for easy tracking
> and collaboration.
[Version control for Designs](https://docs.gitlab.com/ee/user/project/issues/design_management.html)
> In GitLab 12.2 we're also introducing versioned designs to Design Management. Versioned
> designs provide an easy way to see changes to designs over time, making it easier to track
> changes and progress.
[NPM Registry now supports authentication with the GitLab Personal Access Token](https://docs.gitlab.com/ee/user/packages/npm_registry/index.html#authenticating-with-an-oauth-token)
> The GitLab NPM Registry allows Javascript developers to build, publish, and version
> NPM packages using their GitLab instance. NPM requires users to authenticate with
> OAuth and prior to 12.2, the GitLab personal access token did not support OAuth.
> Users were forced to generate their own token (outside of GitLab) in order to use the
> NPM registry, which also prevented them from leveraging two-factor authentication.
> This was not a scalable solution for our enterprise customers.
>
> In 12.2 we are excited to announce that we now support authentication using the GitLab [personal access token](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html).
> The GitLab personal access token works seamlessly with two-factor authentication and allows users
> to choose a scope and expiration policy that works for them. Simply update your .nprmrc file
> with your personal access token and begin publishing and downloading packages to the GitLab NPM Registry.
[Scoped environment variables feature moved to Core](https://docs.gitlab.com/ee/ci/variables/#limiting-environment-scopes-of-environment-variables)
> Initially introduced in [GitLab Premium 9.4](https://about.gitlab.com/releases/2017/07/22/gitlab-9-4-released/#environment-specific-secret-variables),
> the ability to scope environment variables to specific environments has now moved to GitLab Core. This feature provides
> great flexibility when configuring different variables (for example, different private keys to access different environment-related infrastructure)
> and using multiple environments in the development life cycle.
>
> We are open-sourcing this feature in alignment with our [buyer-driven tier designation](https://about.gitlab.com/company/pricing/#the-likely-type-of-buyer-determines-what-features-go-in-what-tier) to encourage its use and contribution by the community.
[List users starring a project](https://docs.gitlab.com/ee/user/profile/#user-profile)
> [Starring](https://docs.gitlab.com/ee/user/project/working_with_projects.html#star-a-project) is a common way to keep
> track of noteworthy projects. Thanks to a community contribution, it's now possible to view a list of
> users who have starred a particular project in the UI by clicking the number of starrers on a project page.
> This list is also available in the [Projects API](https://docs.gitlab.com/ee/api/projects.html#list-starrers-of-a-project).
>
> Starred projects are also available for viewing on the [user profile](https://docs.gitlab.com/ee/user/profile/#user-profile).
>
> Thanks to [Camil Staps](https://gitlab.com/camilstaps) for the contribution!
[Maintainers can create subgroups](https://docs.gitlab.com/ee/user/group/subgroups/index.html#creating-a-subgroup)
> For large organizations prioritizing agility, subgroups are a valuable
> tool for keeping an instance organized as it continues to scale. We're now
> providing the option for group Owners to grant Maintainers the ability to
> create subgroups. With this option enabled, Maintainers in a group will be
> able to move independently and quickly, without requiring intervention from
> group Owners to keep their projects organized.
>
> Thanks to [Fabio Papa](https://gitlab.com/fapapa) for the contribution!
[Kubernetes namespace for each environment](https://docs.gitlab.com/ee/user/project/clusters/#rbac-cluster-resources)
> Using the same Kubernetes cluster for multiple environments can net you some great efficiencies. For example, if dev and stage both use the same cluster, then administrative overhead goes down because you only have one cluster to manage, and infrastructure cost goes down because Kubernetes can schedule pods from both environments onto a smaller set of nodes.
>
> Previously, GitLab didn't support this use case well, all environments in a project were deployed into the same namespace. If you wanted separate permissions for each environment (for example, if you wanted to allow engineering to deploy to dev but not stage) you needed to use a separate cluster for each.
> The GitLab Kubernetes integration now uses a dedicated namespace for each project environment, and you can finely configure permissions separately for each so you can take advantage of the efficiencies that come with using the same cluster for multiple environments.
>
> This will allow Kubernetes users to reuse the same cluster for different environments without having to deploy all environments into
> the same namespace. Additionally, operators are now able to finely configure permissions for each environment to allow users to deploy to some
> but not all environments.
[Uninstall Cert Manager from Kubernetes GitLab Managed Apps](https://docs.gitlab.com/ee/user/clusters/applications.html#uninstalling-applications)
> If you installed Cert Manager to your Kubernetes cluster via the GitLab Kubernetes integration, you can now also uninstall it with a single click from the cluster page.
[Uninstall Helm from Kubernetes GitLab Managed Apps](https://docs.gitlab.com/ee/user/clusters/applications.html#uninstalling-applications)
> If you installed Helm to your Kubernetes cluster via the GitLab Kubernetes integration, you can now also uninstall it with a single click from the cluster page.
[Uninstall Knative from Kubernetes GitLab Managed Apps](https://docs.gitlab.com/ee/user/clusters/applications.html#uninstalling-applications)
>
> If you installed Knative to your Kubernetes cluster via the GitLab Kubernetes integration, you can now also uninstall it with a single click from the cluster page.
[Filter projects by name when importing from Bitbucket Server](https://docs.gitlab.com/ee/user/project/import/bitbucket_server)
> Importing your existing projects from Bitbucket Server into GitLab
> should be an easy process. However if you have thousands of
> projects, it can be challenging to be selective about which
> Bitbucket repositories to import.
>
> In 12.2, we're taking a step to make migrations like these easier by
> introducing a filter on the Bitbucket Server importer page, allowing
> you to specify which repositories you'd like to import by name. We're excited
> to add this filter to all of our project importers in coming releases.
[GitLab chart improvements](https://docs.gitlab.com/charts/) (self-managed only)
> The following improvements have been made to GitLab charts:
>
> - Kubernetes 1.11 is now the minimum supported version
> - `networkproxy` settings for the `registry` [can now be configured](https://docs.gitlab.com/charts/charts/registry/index.html#configuring-the-networkpolicy).
> - Load Balancer settings for `gitlab-shell` [can now be configured](https://docs.gitlab.com/charts/charts/gitlab/gitlab-shell/#loadbalancer-service).
> - Usage of Postgres prepared statements can now [be disabled](https://docs.gitlab.com/charts/charts/gitlab/migrations/#preparedstatements) for `gitlab-migrations`.
[Omnibus improvements](https://docs.gitlab.com/omnibus/) (self-managed only)
> - GitLab 12.2 includes [Mattermost 5.13](https://mattermost.com/blog/mattermost-5-13-community-plugins-devops-integrations-series-b-announcement-and-more/), an [open source Slack-alternative](https://mattermost.com/) whose newest release includes new community plugins, DevOps integrations, and more.
> - In GitLab 12.2, the default count formula for the Unicorn worker has been [adjusted](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/4535) to improve handling of parallel requests in larger deployments. The formula was changed from `CPUs + 1` to `int(CPUs * 1.5 +1)`.
> - GitLab 12.2 packages are now available for [Debian Buster](https://www.debian.org/News/2019/20190706).
> - Updated `nginx` to 1.16.1, TLS v1.3 and ECDSA support is now enabled by default.
> - Updated `postgresql` to 9.6.14 and 10.9.
> - Updated `gitlab-monitor` to 4.2.0, `graphicsmagick` to 1.3.33,
> - To improve security and availability, the Redis `KEYS` command is now disabled by default. If desired, this command and others can be [controlled or obfuscated](https://docs.gitlab.com/omnibus/settings/redis.html#renamed-commands).
> - Added support for [Content Security Policy and nonces](https://docs.gitlab.com/omnibus/settings/configuration.html#content-security-policy) to help protect against JavaScript XSS attacks. These settings are disabled by default.
[Performance improvements](https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&label_name%5B%5D=performance&milestone_title=12.2)
> We continue to improve the performance of GitLab with every release
> for GitLab instances of every size.
>
> Some of the improvements in GitLab 12.2 are:
>
> - [Faster repositioning on issue boards](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/30938)
> - [Labels API response no longer includes issue and merge request counts by default](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/31543)
> - [Faster searching for members of a project or group](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/30451)
> - [Load result counts on inactive search tabs asynchronously](https://gitlab.com/gitlab-org/gitlab-ee/issues/12547)
> - [Use ETag-based caching for merge request widget data](https://gitlab.com/gitlab-org/gitlab-ce/issues/61559)
> - [Reduce number of Gitaly lookups needed to render commit references in Markdown](https://gitlab.com/gitlab-org/gitlab-ce/issues/60449)
> - [Reduce number of queries needed to render list of deploy keys](https://gitlab.com/gitlab-org/gitlab-ce/issues/43080)
> - [Reduce number of Gitaly lookups needed to render submodules](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/30735)
[Manual Issue List Sorting](https://docs.gitlab.com/ee/user/project/issues/sorting_issue_lists.html#manual-sorting)
> It's difficult to order a large list of issues to indicate priority and/or order of implementation, which is necessary for typical use cases such as backlog refinement.
>
> As of 12.2, you can now sort an Issue List in **Manual** mode, which allows you to drag and drop Issues within the list to assign them a relative order.
>
> The order is persisted and maintained across the entire instance for all Project Issue Lists and Group Issue Lists that have **Manual** mode enabled.
[Disable Group Or Project Email Notifications](https://docs.gitlab.com/ee/user/project/settings/#disabling-email-notifications)
> Owners can now disable email notifications at the [Group](https://docs.gitlab.com/ee/user/group/#disabling-email-notifications) or [Project](https://docs.gitlab.com/ee/user/project/settings/#disabling-email-notifications) level, regardless of individual user settings.
>
> If this is activated on a group level, it will cascade down to all sub-groups and projects within the parent group.
[New push options for merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/#git-push-options)
> Using Git push options GitLab already supports opening a merge request, and
> setting it to merge when the pipeline succeeds, all from the Git push
> command. This makes merging small changes fast and easy.
>
> In GitLab 12.2, GitLab has been taught new push options to:
>
> - Set the branch to be removed when it is merged.
> - Change the merge request's title.
> - Change the merge request's description.
[Improved diff expansion](https://docs.gitlab.com/ee/user/project/merge_requests/#incrementally-expand-merge-request-diffs)
> When viewing a diff, most unchanged lines are hidden so that it is easy
> to quickly read the changes. But sometimes more context is needed.
>
> In GitLab 12.2, hidden line ranges can now be revealed in full or
> incrementally. Previously hidden line ranges could only be revealed
> incrementally from the bottom of the range.
[Git Blame API](https://docs.gitlab.com/ee/api/repository_files.html#get-file-blame-from-repository)
> Understanding who last changed a line of code, and why, is helpful for
> making subsequent changes and to know who to ask for feedback. The Git
> `blame` command makes this information easy to find.
>
> In GitLab 12.2, the new Blame API allows this information to be retrieved
> directly from GitLab, without needing to checkout the repository. This is
> helpful for scripting and automation, based on the people who've recently
> changed the file.
>
> Thanks [Oleg Zubchenko](https://gitlab.com/RGBD) for your
> [contribution](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/30675).
[Directed Acyclic Graphs (DAG) for GitLab Pipelines](https://docs.gitlab.com/ee/ci/directed_acyclic_graph/)
> In a simple pipeline, you want all jobs in a stage to complete before moving to the next stage. Many pipelines have all tests should pass before starting to deploy. But with more complex pipelines you might want jobs in one stage to start before the previous stage has finished. For example, when a project generates both Android and iOS apps in a multi-stage pipeline, you likely want the iOS deployment to start as soon as all the iOS tests pass rather than waiting for all the Android tests to pass too. The total compute time might be the same, but the wall-clock time is different.
>
> To address use cases like this and give you a powerful and flexible tool for defining complex pipelines we've added the `needs:` keyword for defining relationships between jobs in your `.gitlab-ci.yml`. The `needs` keyword lets you specify one job as a prerequisite for another job. Once the prerequisite job successfully completes, the job that depends on it in the next stage will kick off immediately without waiting for any other jobs in the previous stage to complete.
>
> In the internals of GitLab, we've implemented this functionality using a [Directed Acyclic Graph (DAG)](https://en.wikipedia.org/wiki/Directed_acyclic_graph). Essentially, when GitLab generates a pipeline from your configuration it's using a complex ruleset to determine the sequencing of your jobs rather than simply gating all jobs in a stage until the previous stage completes. This allows for much more efficient pipeline execution and lays a foundation for [more advanced capabilities on the way](https://gitlab.com/groups/gitlab-org/-/epics/1716).
>
> You can get started with the `needs` keyword today for building pipelines like the example above as well as interesting new monorepo use cases where several unrelated services are kept in a single repository and don't all need to be built/wait for each other.
[Specify variables when running a manual job](https://docs.gitlab.com/ee/ci/pipelines/index.html#specifying-variables-when-running-manual-jobs)
> It is now possible when starting a manual job to override/provide new variables
> that will be used by the running job. This will make it much easier to set up configurable
> custom and/or reusable jobs as part of your pipelines, as well as make it easier to
> troubleshoot when implementing pipeline jobs.
[Lockfile to prevent multiple runner instances on a single host](https://docs.gitlab.com/runner/)
> Running multiple instances of the gitlab-runner process on a single host can cause some extremely
> confusing and hard to debug behaviors. Since this is not the intended usage, we've introduced a
> lockfile that will prevent this from accidentally occurring.
[Improved examples for automatic test splitting](https://docs.gitlab.com/ee/ci/yaml/#parallel)
> We already have the parallel keyword which gives control and flexibility to set up parallel
> tests (or really run any job in a parallel fashion), but this requires a lot of setup from
> a developer and sometimes the split logic just gets duplicated. There are open source solutions
> like [Test Boosters](https://github.com/renderedtext/test-boosters/) that take this a step further by also
> separating the test configuration into multiple files, handling that part of the configuration for you.
> We've updated our documentation for the `parallel` keyword to make this more obvious and
> help more teams get the most out of their pipelines.
[Improved variable masking for `@` and `:` characters](https://docs.gitlab.com/ee/ci/variables/#masked-variables)
> We have added support for two additional characters in variable masking,
> improving the ability for GitLab to automatically hide more, different
> kinds of secrets than it is able to today.
[GitLab Runner 12.2](https://docs.gitlab.com/runner)
> We're also releasing GitLab Runner 12.2 today! GitLab Runner is the open-source project that is used to run your CI/CD jobs and send the results back to GitLab.
>
> ##### Most interesting changes:
>
> - [Locking mechanism to prevent multiple instances of `gitlab-runner` process using the same configuration file](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1496)
> - [Configuration file template for registration command](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1263)
>
> List of all changes are found in GitLab Runner's [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/v12.2.0/CHANGELOG.md).
[Multi-select delete for the Container Registry](https://docs.gitlab.com/ee/user/packages/container_registry/index.html)
>
> Practicing proper container registry hygiene is important. Over time, images can accumulate and take up a significant amount of disk space. Additionally, too many tags can significantly slow down the load time of the container registry management page at **Packages > Container Registry** making it difficult to use.
>
> Previously, there have been a few options for maintaining your registry, each with their own challenges. You could use the [bulk tag delete API](https://docs.gitlab.com/ee/api/container_registry.html#delete-repository-tags-in-bulk) and [garbage collection](https://docs.gitlab.com/omnibus/maintenance/#container-registry-garbage-collection) to automate clean up, but this requires you to write and maintain a script. You could also manually delete images and tags from the management page, but this is very time-consuming as each image tag needed to be deleted one at a time.
>
> Now, we've updated and improved the GitLab UI to make manual pruning significantly faster. You can select multiple tags at a time and selecting an image will automatically select all of the associated tags. This should make it easier to maintain your registry, lowering your storage costs, and keeping page performance snappy. We're happy to release this iteration of the container registry and have more improvements on the way. Be on the lookout for future improvements such as the ability to set [policy for retention and expiration](https://gitlab.com/gitlab-org/gitlab-ce/issues/20247).
[Embed Prometheus metrics in issues](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#embedding-metric-charts-within-gitlab-flavored-markdown)
> Metrics charts help to visualize what changed to trigger an incident. Displaying metric charts directly
> in issues allows you to get started right away when a new incident issue is generated instead of needing
> to open dashboards to find metrics from the timeframe of the alert. While working an incident an on-call
> engineer can use embedded charts to share knowledge and context they've gained by exploring the metrics
> and logs. After the incident is over, the team performing a retrospective will have all of the charts in
> one place including metrics from the initial alert and all of the forensic work done during the firefight.
>
> To embed metrics charts in issues, simply generate a shareable link on the chart in the metrics dashboard.
> You can specify the timeframe for the data using the dahsboard time filter and this will be saved in the URL.
> Pasting this URL in the description embeds the visualizations in the issue.
>
> When an incident issue is generated by an alert it can make use of a pre-configured template. Adding a
> metric chart to the issue template will automatically embed a chart showing metrics scoped to the time of the alert.
[Download CSV of Prometheus charts on the metrics dashboard](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#monitoring-cicd-environments)
> Many people use a screen-reader to interact with GitLab. In order for screen readers to
> verbalize content, they need visual information, like charts, to be conveyed via text.
> GitLab can generate chart data as a CSV file that can be downloaded and fed into a
> screen-reader application. This can be done by accessing the drop-down menu in the upper-right
> corner of the desired chart and selecting the option to download the CSV.