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