12.2

GitLab 12.2 Release

GitLab 12.2 released with Directed Acyclic Graphs for Pipelines and Design Management

GitLab 12.2 released with Directed Acyclic Graphs for Pipelines, Design Management, Cross-project Merge Request dependencies, and much more!

GitLab 12.2 is an exciting release that will help teams optimize their pipelines, improve collaboration, and manage interdependencies between projects. Read on to learn more.

Faster, more flexible pipelines

The goal of CI pipelines are to automate manual build and testing tasks, accelerating software delivery while reducing errors and mistakes. However for some use cases, GitLab CI/CD pipelines are not as efficient as they could be. With GitLab 12.2, we now support Directed Acyclic Graphs (DAG) as a method to create and manage detailed job dependencies, rather than relying on sequential stages. This is incredibly powerful and makes it possible for your CI pipelines to become both faster and more efficient.

Design Management

Software development is a team sport, and our goal is to make it easy for everyone to contribute. In 12.2, we’re delivering new capabilities to include designers and design management in GitLab. Design Management will make it easy to share, version, and collaborate on design artifacts, helping teams to be more efficient with a single source of truth.

This is just the beginning of focusing on designer specific workflows inside of GitLab and we'd love for you to contribute to our Design Management Strategy.

Cross Project Merge Request Dependencies

Complex systems often span multiple projects with interdependencies between code changes, where the sequence of merging changes matters. GitLab now supports Cross-project Merge Request Dependencies, making it possible to define these dependency relationships and prevent mistakes due to changes being merged in the wrong order. Fewer mistakes mean you’re able to reduce rework, and deploy your changes faster.

And much more!

There are so many great features within GitLab 12.2 that we couldn’t possibly highlight them all. Restrict group membership by domain, Feature Flag Percent Rollout Strategy and Feature Flag User ID rollout Strategy, Security approval in Merge Requests, and now scoped environment variables being included in Core. Keep reading below to get details on every feature!

Register now to join us at our first user conferences in Brooklyn and London!

Join us for an upcoming event

GitLab MVP badge

MVP This month's Most Valuable Person (MVP) is awarded to Fabio Papa

Fabio’s contribution to GitLab 12.2 adds a new setting which allows Maintainers to create sub-groups, in addition to Owners. Fabio has also contributed valuable changes to GitLab 12.0 and GitLab 11.10.

Thanks so much to Fabio for your contributions!

12.2 Key improvements released in GitLab 12.2

Directed Acyclic Graphs (DAG) for GitLab Pipelines

Directed Acyclic Graphs (DAG) for GitLab Pipelines

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). 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.

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.

Directed Acyclic Graphs (DAG) for GitLab Pipelines

Annotations for Designs

Annotations for Designs

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.

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) to be enabled.

Cross-project Merge Request Dependencies

Cross-project Merge Request Dependencies

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.

Cross-project Merge Request Dependencies

Restrict group membership by domain

Restrict group membership by domain

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.

Restrict group membership by domain

Percent Rollout Strategy for Feature Flags

Percent Rollout Strategy for Feature Flags

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

User ID Rollout Strategy for Feature Flags

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.

User ID Rollout Strategy for Feature Flags

Security approval in Merge Requests

Security approval in Merge Requests

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 approval in Merge Requests

Specify variables when running a manual job

Specify variables when running a manual job

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.

Specify variables when running a manual job

Scoped environment variables feature moved to Core

Scoped environment variables feature moved to Core

Initially introduced in GitLab Premium 9.4, 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 to encourage its use and contribution by the community.

Scoped environment variables feature moved to Core

12.2 Other improvements in GitLab 12.2

NPM Registry now supports authentication with the GitLab Personal Access Token

NPM Registry now supports authentication with the GitLab Personal Access 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. 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.

Maintainers can create subgroups

Maintainers can create subgroups

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 for the contribution!

Maintainers can create subgroups

Improved diff expansion

Improved diff expansion

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.

Improved diff expansion

Assign groups as code owners

Assign groups as code owners

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

Design Management uploads

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.

Multi-select delete for the Container Registry

Multi-select delete for the Container Registry

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 and 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.

Multi-select delete for the Container Registry

Kubernetes namespace for each environment

Kubernetes namespace for each environment

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 Helm from Kubernetes GitLab Managed Apps

Uninstall Helm from Kubernetes GitLab Managed Apps

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.

Disable Group Or Project Email Notifications

Disable Group Or Project Email Notifications

Owners can now disable email notifications at the Group or Project 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.

Lockfile to prevent multiple runner instances on a single host

Lockfile to prevent multiple runner instances on a single host

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 variable masking for @ and : characters

Improved variable masking for @ and : characters

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.

Label issues opened by Prometheus alerts with incident

Label issues opened by Prometheus alerts with incident

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.

Read and write admin notes for a user via API

Read and write admin notes for a user via API

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.

Security Dashboard as default view for groups

Security Dashboard as default view for groups

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.

Security Dashboard as default view for groups

GitLab chart improvements

GitLab chart improvements

The following improvements have been made to GitLab charts:

List users starring a project

List users starring a project

Starring 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.

Starred projects are also available for viewing on the user profile.

Thanks to Camil Staps for the contribution!

List users starring a project

New push options for merge requests

New push options for merge requests

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.

Bulk edit issue labels at the group level

Bulk edit issue labels at the group level

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.

Git Blame API

Git Blame API

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 for your contribution.

Version control for Designs

Version control for Designs

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.

Version control for Designs

Manual Issue List Sorting

Manual Issue List 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.

Manual Issue List Sorting

Uninstall Cert Manager from Kubernetes GitLab Managed Apps

Uninstall Cert Manager from Kubernetes GitLab Managed Apps

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 Knative from Kubernetes GitLab Managed Apps

Uninstall Knative from Kubernetes GitLab Managed Apps

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

Filter projects by name when importing from 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.

Filter projects by name when importing from Bitbucket Server

Improved examples for automatic test splitting

Improved examples for automatic test splitting

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 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.

Label and annotate issues using GLFM in alerts from external Prometheus instances

Label and annotate issues using GLFM in alerts from 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) can be added to your alert configuration files in AlertManager and used to automatically assign and label issues that are opened on alerts.

Embed Prometheus metrics in issues

Embed Prometheus metrics in issues

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.

Embed Prometheus metrics in issues

Download CSV of Prometheus charts on the metrics dashboard

Download CSV of Prometheus charts on the metrics dashboard

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.

Download CSV of Prometheus charts on the metrics dashboard

GitLab Runner 12.2

GitLab Runner 12.2

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:

List of all changes are found in GitLab Runner’s CHANGELOG.

Omnibus improvements

Omnibus improvements

  • GitLab 12.2 includes Mattermost 5.13, an open source Slack-alternative 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 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.
  • 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.
  • Added support for Content Security Policy and nonces to help protect against JavaScript XSS attacks. These settings are disabled by default.

Deprecations Deprecations

Remove Kubernetes service integration page

Remove Kubernetes service integration page

The Kubernetes service integration page has been removed in 12.2 in favor of the instance-level cluster functionality introduced in GitLab 11.11.

Planned removal date: August 22nd, 2019.

Internal visibility disabled on GitLab.com for new projects, groups, and snippets

Internal visibility disabled on GitLab.com for new projects, groups, and snippets

The Internal visibility setting is useful for self-managed instances interested in making a project available for any registered user. When used on instances where user registration is restricted, it can become a tool to encourage innersourcing.

On GitLab.com, however, user registration is open and available to the general public. Since anyone can register and gain read access to resources with Internal visibility, there’s little difference between the Internal and Public setting.

As a result, new projects, groups, and snippets may only be created as Public or Private as of July 30, 2019. Existing resources set to Internal remain unchanged on GitLab.com, and will be migrated to the Private visibility setting in the near future. Owners may consider changing visibility settings earlier.

Planned removal date: July 30, 2019.

Ruby 2.6 required

Ruby 2.6 required

Beginning with GitLab 12.2, Ruby 2.6 is required to run GitLab. Omnibus GitLab and the GitLab Chart already ship with Ruby 2.6.3, but users of source installations that run Ruby 2.5 or older will have to upgrade.

Planned removal date: Aug. 22, 2019

Removals and breaking changes Removals and breaking changes

The complete list of all removed features can be viewed in the GitLab documentation. To be notified of upcoming breaking changes, subscribe to our Breaking Changes RSS feed.

Important notes on upgrading to GitLab Important notes on upgrading to GitLab 12.2

  • As detailed in the critical security release blog post, existing Grafana data will be backed up, Grafana will be reset to the initial configuration, and GitLab SSO will be the only authentication mode available.
  • Rails’ authenticated cookie encryption is now enabled and old sessions are automatically upgraded. However, session cookie downgrades are not supported. So after upgrading to 12.2, any downgrades would result to all sessions being invalidated and users are logged out.
  • Similar to GitLab 12.0 and GitLab 12.1, GitLab 12.2 will automatically upgrade the PostgreSQL version to 10.9.
  • You can skip the auto-upgrade to PostreSQL 10.9 by creating /etc/gitlab/disable-postgresql-upgrade.

Changelog Changelog

Please check out the changelog to see all the named changes:

Installing Installing

If you are setting up a new GitLab installation please see the download GitLab page.

Updating Updating

Check out our update page.

Questions? Questions?

We'd love to hear your thoughts! Visit the GitLab Forum and let us know if you have questions about the release.

GitLab Subscription Plans GitLab Subscription Plans

  • Free

    Free-forever features for individual users

  • Premium

    Enhance team productivity and coordination

  • Ultimate

    Organization wide security, compliance, and planning

Try all GitLab features - free for 30 days

Cover image licensed under Free

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.

Share your feedback

Take GitLab for a spin

See what your team could do with The DevSecOps Platform.

Get free trial

Have a question? We're here to help.

Talk to an expert
Edit this page View source