GitLab 12.2 is here and oh my can you create complex pipelines now

GitLab 12.2 is here and oh my can you create complex pipelines now
Gitlab Logo

The team behind repository management project GitLab stuck to their timetable and just released version 12.2 of the GitHub competitor into the wild.

With the new version, GitLab tackled the problem of increasingly complex pipelines by introducing directed acyclic graphs into the Pipelines component. Users now have a needs: keyword available to them, which allows the definition of jobs as prerequisites for running others. Like that, your system doesn’t have to wait for a whole stage to finish before starting a job in the next one, but only wait for the defined job to be completed. 

If a job is started manually, GitLab 12.2 lets users provide new variables for running the process which can be useful when troubleshooting for example. Speaking of manual, if you like your project’s issue in a particular order, you can now use Manual mode to arrange them to your liking. On top of that, there is now the option of embedding Prometheus metrics into an issue.

Starting in version 12.2, GitLab uses dedicated Kubernetes namespaces for each project environment, which makes using the same cluster for multiple environments easier.

Other enhancements available to all users include new push options for merge request, for example the possibility to change the title of a request and remove the branch once it’s merged. Also, group owners can now grant maintainers the ability to create subgroups and disable email notification on group or project level. 

Subscribers of the premium/silver and ultimate/gold versions of GitLab can have a look at “Annotations for Designs” – an alpha feature that marks the beginning of the integration of a designer specific workflow. If Large File Storage is enabled, it gives teams the chance to collect feedback for designs and discuss them within issues.

Version 12.2 comes with cross-project merge request dependencies, which are meant to help users prevent changes from being merged in the wrong order, should a new feature require changes in multiple components, and raise visibility for inter-project relationships. It also adds a new “percentage rollout” strategy, so that only a defined percentage of logged-in users are subjected to the consequences of a newly enabled feature flag.

If your new features should only be visible to very specific users, a “User ID” rollout strategy lets you specify the IDs of those that should test it. In terms of access management, admins and group owners can now restrict group membership to users with email addresses matching a specific domain name

The release includes version 12.2 of GitLab Runner, which comes with a locking mechanism to prevent multiple instances of the tool from using the same configuration file amongst other things. A complete list of changes can be found in the GitLab changelogs for the Community and Enterprise Edition.