GitLab 12.2: directional acyclic graphs for pipeline and design management



The exciting release of GitLab 12.2 will help teams streamline pipelines, expand collaboration, and manage project interdependencies. Details below.







Faster and more flexible pipelines



CI pipelines are needed to automate assembly and testing tasks in order to speed up software delivery and avoid manual inherent errors. But in some cases, the efficiency of GitLab CI / CD pipelines is far from ideal. GitLab 12.2 now supports directional acyclic graphs (DAGs) to create and manage detailed task dependencies rather than relying on sequential steps. This is a super-efficient tool with which your CI pipelines will work faster and more productively.







Design management



Software development is a team sport, and we want to make it accessible to everyone. In release 12.2, we offer new features to enable designers and design management in GitLab. Design management will make it easier to submit, version control, and collaborate on design artifacts to make team work even more effective with a single source of truth.







We are just starting to work on design workflows on GitLab and will be happy if you contribute to our design management strategy .







Marge request dependencies between projects



In complex systems, there are often several projects with interdependencies between code changes, where it is important in which order the changes are applied. GitLab now supports merge request dependencies between projects to determine dependency relationships and prevent errors associated with applying changes in the wrong order. The fewer errors, the less you have to redo and the faster you can deploy the changes.







And that's not all!



GitLab 12.2 has so many cool features that it’s simply impossible to talk about all of them. Limiting group memberships by domain , deployment strategy by percent and user IDs for function switches , security approval in merge requests and now environment variables with scope are included in the Core version . Read on and learn more about each feature.







This Month's Most Valuable Employee ( MVP ) - Fabio Papa



Thanks to Fabio, a new parameter has appeared in GitLab 12.2 , with which not only the owners, but also the maintainers can create subgroups. Fabio also made a valuable contribution to the releases of GitLab 12.0 and GitLab 11.10 .



Thank Fabio


Main features of GitLab 12.2



Directional acyclic graphs for GitLab pipelines



CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD







In a simple pipeline, all tasks in one stage must be completed before moving on to the next stage. In many pipelines, you need to go through all the tests before deployment. But in more complex pipelines, sometimes you want tasks at one stage to begin before the completion of the previous stage. For example, a project creates applications for Android and iOS in a multi-stage pipeline. Most likely, you will want the deployment of iOS applications to begin immediately after passing the tests for iOS, so as not to wait until all the tests for Android have been passed. The total calculation time will be the same, and the physical time will be different. To simplify the work in such cases and give you an effective and flexible tool for defining complex pipelines, we added the needs:



keyword, which defines the relationship between jobs in .gitlab-ci.yml



. With the needs



keyword, you can specify that one task must be completed after another. When the first task is completed, the task depending on it in the next stage will immediately begin to be executed, without waiting for the rest of the tasks in the previous stage. Inside GitLab, we implemented this function using a directed acyclic graph . In fact, when GitLab creates a pipeline from your configuration, it uses a complex set of rules to determine the sequence of tasks, and not just start to complete tasks at one stage only after completing the previous one. Firstly, the pipeline is performed more efficiently, and secondly, based on this, other advanced features can be implemented. Use the needs keyword today to create pipelines, as in the example above, or use it in interesting new mono-repository scenarios when several unrelated services are stored in the same repository and should not wait for each other.













Design Annotations



PREMIUM, ULTIMATE, SILVER, GOLD







Using design annotations, designers and developers can work together on designs, leaving comments on various aspects. By resolving task designs in support of this collaboration, we continue to refine tasks as a single source of truth on GitLab. At the same time, we provide a framework for feedback and design discussions.







We are just starting to work on design workflows on GitLab and will be happy if you contribute to our strategy .







Design management is currently at the alpha stage and is subject to change at any time without prior notice. For design management, you need to enable Large File Storage (LFS) .









Marge request dependencies between projects



PREMIUM, ULTIMATE, SILVER, GOLD







Companies that release several related products often use common services and libraries so as not to solve the same problem twice. Usually they are stored in separate projects, but in this case it is difficult to coordinate changes between services and their consumers if you need to change the function in several components.







In GitLab 12.2, merge request dependencies between projects allow you to define dependency relationships so that the changes are not applied in the wrong order. It’s also convenient to look at these relationships in the code review, so that it is easier for reviewers to understand all the changes.













Group membership restrictions by domain



PREMIUM, ULTIMATE, SILVER, GOLD







For security-conscious organizations, it is important to control access to projects and teams to manage risk. In release 12.2, we add an access control tool for administrators and group owners. Now you can grant group membership only to users with an email address in the specified domain.







This means that at YourCompany only users with yourcompany.com addresses can be included in the group, and owners will not be able to accidentally add unauthorized users.













Percentage Deployment Strategy for Feature Switches



PREMIUM, ULTIMATE, SILVER, GOLD







You can now select a percentage deployment strategy for feature switches. When deployed by percentage, you can individually set the percentage for each environment and each switch. When the percentage deployment is configured and the switch is enabled, the function will be shown to the configured percentage of logged-in users. This allows you to perform controlled deployments and monitor the behavior of the target environment to get the expected results.









User Identity Deployment Strategy for Feature Switches



PREMIUM, ULTIMATE, SILVER, GOLD







You can now select a deployment strategy by user ID for feature switches. This strategy allows you to specify a list of user identifiers, separated by commas, and then enable the function for only some users. You can also test functions only on certain groups or segments of the user base.













Marge Requests Security Approval



ULTIMATE, GOLD







Now it is possible to guarantee that merge requests that introduce new vulnerabilities will not be applied until responsible persons review and approve the change.







So it will be easier for you and your teams to comply with requirements and policies, and new vulnerabilities will not be able to accidentally leak into the code base.













Specifying variables when starting a task manually



CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD







Now when you start a task manually, you can redefine or provide new variables that the task will use. So it will be much easier to set up custom or reusable tasks in pipelines, and even troubleshoot tasks.













Scope Environment Variables Now Available in Core



CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD *







The ability to limit environment variables to a specific area appeared in GitLab Premium 9.4 , and is now available for GitLab Core. This feature provides the flexibility to configure various variables (for example, different private keys to access different infrastructures in environments) and use multiple environments in the development life cycle.

We open the source code of this feature in accordance with our division into levels by type of buyer , so that everyone can use it and participate in its development.













Other improvements in GitLab 12.2



NPM registry now supports authentication with GitLab personal access token



PREMIUM, ULTIMATE, SILVER, GOLD







The GitLab NPM Registry allows Javascript developers to compile, publish, and version NPM packages using their GitLab instance. NPM requires authentication with OAuth, and prior to release 12.2, the GitLab personal access token did not support OAuth. Users had to create their own token (outside of GitLab) in order to use the NPM registry, and it was impossible to use two-factor authentication. This solution did not scale for corporate clients.







We are pleased to announce that in release 12.2 we support authentication with the GitLab personal access token. GitLab Personal Access Token works with two-factor authentication and allows users to choose the scope and expiration policy. Just add your personal access token to the .nprmrc



file and enter the GitLab NPM registry to publish and download packages.







List of users starring a project



CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD







To keep track of worthy projects, you can mark them with a star . Thanks to community input, you can now see a list of users who have tagged a specific project. To do this, click on the number of such users on the project page. The list is also available in the Projects API .







Marked projects can be viewed in the user profile .







Thanks for the contribution, Camil Staps !













Maintainers can create subgroups



CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD







In large organizations that need flexibility, subgroups help maintain order in a growing instance. Owners can now allow maintainers to create subgroups. With this option, the maintainers in the group will be able to act quickly and independently, without resorting to the owners of the group for help.







Thanks for the contribution, Fabio Papa !













New push options for merge requests



CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD







GitLab already supports the opening of merge requests and setting up their application after the successful completion of the pipeline - and that's all in the Git push team. Now applying small changes is quick and easy.







GitLab 12.2 released new push options:









Improved diff file deployment



CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD







When viewing a diff file, most lines are hidden without changes so that the changes are immediately visible. But sometimes you need more context.







In GitLab 12.2, hidden row ranges can be opened completely or gradually. Previously, hidden row ranges could only be opened gradually, from the bottom of the range.













Batch editing task shortcuts at the group level



PREMIUM, ULTIMATE, SILVER, GOLD







Users can change the shortcuts of many tasks simultaneously in one project. GitLab 12.2 introduces the ability to batch edit shortcuts for many tasks at the group level to make shortcuts easier to manage.







Assigning Groups as Code Owners



STARTER, PREMIUM, ULTIMATE, BRONZE, SILVERGOLD







It is often not obvious who should check for changes. It will be easier if you assign code owners to files. After the appointment, you see the owners when viewing the file and automatically add them as approvers for the merge requests.

In GitLab 12.2, you can now assign entire groups to code owners, not just users by name on GitLab and email. If you assign a group, code owners will not be left behind in case of team changes, especially when using LDAP to manage group memberships.







Git Blame API



CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD







It is useful to know who last changed the line of code and why, in order to make subsequent changes and understand who to ask feedback. With the Git blame



team, this information is easy to find.







In GitLab 12.2, the new Blame API retrieves this information directly from GitLab, and not through the repository. This is useful for scripts and automation based on users who have recently changed a file.







Thank you Oleg Zubchenko for your contribution .







Design Management Downloads



PREMIUM, ULTIMATE, SILVER, GOLD







Designers and developers can now work together on designs within the GitLab task thanks to the download function for managing design on GitLab. Designs can be uploaded to a new area within the task for easy tracking and collaboration.









Version Control for Designs



PREMIUM, ULTIMATE, SILVER, GOLD







In GitLab 12.2, we introduce version control for designs. Thanks to version control, you can easily view changes over time and track these changes and progress.













Multiple deletion for container registry



CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD







It is very important to keep order in the container registry. Over time, images accumulate and clutter up the disk. If there are too many tags, the loading time of the container registry management page in Packages> Container Registry is stretched, and it can be difficult to use.







Previously, there were only a few registry management options, all with their own flaws. You could use the bulk tag removal API and garbage collection to automate the cleanup, but for this you had to write and maintain a script. It was also possible to manually remove images and tags from the control page, but this takes too much time, because you have to delete one at a time.







Now the GitLab interface allows you to manually tidy up much faster. Select several tags at once, and if you select an image, all tags associated with it will be selected automatically. Maintaining the registry will now be easier, and you will save on storage and will maintain page performance. We are pleased to present this addition in the container registry and are preparing new convenient things. Do not miss future improvements, such as the ability to customize retention policies and expiration dates .













Manual task list



CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD







Organizing a large list of tasks is not easy - you need to specify the priority and order of implementation, for example, to clean up the backlog.







In release 12.2, you can sort the task list manually in Manual mode, where you can drag and drop tasks on the list and arrange them in any order.







The order is saved in the whole instance for all project task lists and task lists of groups where Manual mode is enabled.













Kubernetes namespace for each environment



CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD







Using a single Kubernetes cluster for multiple environments can be beneficial. For example, if you use one cluster for development and staging, administrative costs are reduced, because you need to manage only one cluster. And you can save on infrastructure - Kubernetes will plan pods from both environments on fewer nodes.







Previously, GitLab did not sufficiently support such scenarios, and all environments in the project were deployed in the same namespace. If you needed different permissions for each environment (for example, you wanted to allow engineers to deploy to the development environment, but not staging), you had to start a separate cluster. GitLab Kubernetes integration now uses a dedicated namespace for each project environment, and you can fine-tune permissions for each environment to fully enjoy the benefits of using a single cluster for multiple environments.







Kubernetes users will be able to use the same cluster for different environments, and they will not have to deploy all the environments in the same namespace. Also, operators can configure permissions for each environment in detail, so that users can deploy to some environments, but not to all.







Uninstall Cert Manager from Kubernetes GitLab Managed Applications



CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD







If you installed Cert Manager in a Kubernetes cluster through GitLab Kubernetes, you can now remove it with one click on the cluster page.







Removing Helm from Kubernetes GitLab Managed Applications



CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD







If you installed Helm in a Kubernetes cluster through GitLab Kubernetes, now you can remove it with one click on the cluster page.







Removing Knative from Kubernetes GitLab Managed Applications



CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD







If you installed Knative in a Kubernetes cluster through GitLab Kubernetes, now you can remove it with one click on the cluster page.







Turn off email notifications mail for a group or project



CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD







Now owners can turn off notifications at the group or project level, regardless of individual user settings.

If you turn off group-level notifications, it will affect all subgroups and projects in the parent group.







Filter projects by name when importing from Bitbucket Server



CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD







Importing existing projects from Bitbucket Server to GitLab should be simple. But if there are thousands of such projects, you are tormented by choosing Bitbucket repositories.







In release 12.2, we simplify these migrations and present a filter on the Bitbucket Server import page, where you can specify the names of the repositories that you want to import. We are pleased to add this filter to all importers of the project in future releases.













Lock file that does not allow multiple instances of the runner on the same host



CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD







Running multiple gitlab-runner instances on the same host can be confusing and make debugging more difficult. This should not be so, therefore we present a lock file that will prevent this random event.







Improved examples for automatic test separation



CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD







We already have the parallel keyword, with which you can control and flexibly configure parallel tests (or perform any task in parallel at all), but the developer has to configure a lot, and sometimes the separation logic is simply duplicated. There are open source solutions, for example Test Boosters , which improve this process and split the test configuration into several files, automating this part of the setup. We updated the documentation for the parallel



keyword to make the process more obvious and improve the efficiency of the piplines.







Improved masking of variables for @ and: characters



CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD







We've added support for two extra characters in masking variables, and now GitLab can automatically hide more different secrets than it does now.







Shortcuts and annotations for tasks using GFM in alerts from external Prometheus instances



ULTIMATE, GOLD







If you have a Prometheus instance that is managed outside of GitLab, we have simplified the sorting and assignment of incidents. We have added the gitlab_incident_markdown field where GitLab is looking for alerts. It is displayed above the incidents in the Summary section. GFM ( GitLab Flavored Markdown ) can be added to alert configuration files in AlertManager and used to automatically assign and mark tasks opened by alerts.







Shortcuts for tasks opened by Prometheus incident alerts



ULTIMATE, GOLD







If you set up a project to open Prometheus alert tasks, the incident



shortcut will be applied automatically. Therefore, now the incident response team will be able to easily sort them on task boards, and they will not have to manually mark tasks based on incidents and tasks of a different type.







Prometheus built-in metrics in tasks



CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD







, . , , , . , , . , , , , .







, . , URL. URL , .







, . , , .













API



STARTER, PREMIUM, ULTIMATE







GitLab. GitLab.com note



, . , , . API , .







CSV- Prometheus



CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD







GitLab . , , , . GitLab CSV-, . CSV-.















ULTIMATE, GOLD







, . , .







, , , .













GitLab Runner 12.2



CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD







GitLab Runner 12.2! GitLab Runner β€” , CI/CD GitLab.







:









GitLab Runner: CHANGELOG .







GitLab



CORE, STARTER, PREMIUM, ULTIMATE







GitLab:









Omnibus



CORE, STARTER, PREMIUM, ULTIMATE











CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD







GitLab GitLab .







GitLab 12.2:











Kubernetes



Kubernetes 12.2. , GitLab 11.11.







: 22 2019 .







Internal () GitLab.com , .







Internal , . , , innersource .







GitLab.com . Internal, Internal Public ( ) .







30 , (Public) (Private). Internal Private . .







: 30 2019 .







Ruby 2.6



GitLab 12.2 Ruby 2.6. Omnibus GitLab GitLab Chart Ruby 2.6.3, Ruby 2.5 .







: 22 2019 .







GitLab 12.2



, Grafana, Grafana , GitLab SSO .

cookie Rails , . cookie . 12.2 , , .

GitLab 12.0 GitLab 12.1, GitLab 12.2 PostgreSQL 10.7 .

PostreSQL 10.7, /etc/gitlab/disable-postgresql-upgrade



.









:









Installation



GitLab, GitLab .







Update



.








All Articles