💊 🐁 🕰️ GitLab 12.5 released with the creation of EKS clusters and the environment panel 👧🏽 🔖 🥅

A picture to attract attention

A new GitLab release has been released with the creation and deployment of EKS clusters, Crossplane support, an environment panel and many other cool features!

For the most efficient delivery of quality software, you need to support a wide range of infrastructure and several cloud platforms . This month's GitLab release makes it easy to set up, monitor and manage projects with a variety of configurations.

Create and Deploy EKS Clusters from GitLab

Like 85% of enterprise platforms, GitLab relies on the multicloud approach . It’s critical for our users to deploy their applications to the cloud of their choice without any problems. We are aware of this and are happy to present the opportunity to create Kubernetes clusters on Amazon's EKS in just a few clicks. This process is as simple as building clusters on GKE from Google . Just select EKS, configure the created cluster, GitLab will automatically allocate resources and prepare your cluster, and you can easily and quickly place your applications on it. GitLab eliminates the need to manually complete the complex part of creating a cluster.

Now this feature is switchable, and is enabled by default on GitLab.com.

Work with managed cloud services with Crossplane

We believe that operational efficiency is very important, and therefore we are pleased to introduce Crossplane integration as an application in GitLab Managed Apps . Crossplane simplifies working with cloud service dependencies by allowing administrators to declaratively configure and securely use the managed services installed in the selected cloud, including GCP, AWS, and Azure. Integration with Auto DevOps simplifies resource allocation before declaring a CI variable.

Quick view of environment status

Sometimes you encounter frequent changes in the application that are pretty hard to track as they go their way through your dev, staging, and production environments. A new panel of environments collects in one place information on the status of all environments in all groups and projects. This means that you can quickly find and identify problems. For example, “Does the environment not work because the code is now deploying, or is it really not working?”

And even more!

12.5 is a great release, and there are a lot of innovations awaiting you. Separately, we want to note the integration with Sourcegraph and several security improvements. Read on to find out all about this month's new release features!

By the way, how about a meeting? Registration is open for the next GitLab Commit user conference , which will take place on January 14th in San Francisco.

Join us at the GitLab Commit ; fill out the release survey (in English).

GitLab MVP badge

This month's MVP - gfyoung

The user gfyoung made more than 30 merge requests (in the Russian localization of GitLab “merge requests”) to add frozen_string_literals to the frozen_string_literals tests to improve performance and consistency, and this is not counting the many merge requests in the code of GitLab itself over the past year. It's great to see an iterative approach in action, and we are very grateful to gfyoung for this work!

Key features of the release of GitLab 12.5

Easily create and deploy EKS clusters from GitLab

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) DevOps loop stage: "Configure"

Kubernetes is unforgivably complex, so creating a cluster from scratch is no easy task. Even with services like AWS's Elastic Kubernetes Service (EKS), which hide some of the complexity behind abstraction, it still takes many more steps just to get started. Manual configuration, such as creating a special Kubernetes control plane and individual nodes in EC2, distracts you from the main goal - to launch your applications. At GitLab, we strive to automate all repetitive tasks and want to simplify the creation of a new cluster. That is why we are adding integration with EKS in release 12.5.

Now on the clusters page you can select the EKS option (this requires logging into your AWS account). After logging in, simply select the necessary parameters for your cluster, and GitLab will take care of the rest.

EKS integration is important not only for the convenience of working with Kubernetes on AWS, it is also part of our multicloud strategy. Together with GKE integration, we hope to make it easier not only to configure Kubernetes, but also switch to multicloud. And this is just the beginning, we want our users to have a wide selection of cloud providers for deployments. You can use any provider with its strengths and be able to move your applications to the selected cloud without changing your usual workflow in GitLab.

Now this feature is switchable, and is enabled by default on GitLab.com. To enable it in user instances, start the Rails console: gitlab-rails console and run Feature.enable(:create_eks_clusters) .

Documentation on creating EKS clusters and the original ticket .

Crossplane in GitLab Managed Apps

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) DevOps loop stage: "Configure"

Previously, Kubernetes applications could be launched using GitLab, but service dependencies had to be separately configured, connected, and secured. Starting with release 12.5, cloud services can now be configured declaratively with the Crossplane open source project, which inherits the Kubernetes API for managing services such as PostgreSQL, MySQL, Redis, and Storage Buckets.

Crossplane is now available as the GitLab Managed App. You can install it in any Kubernetes cluster running GitLab. Managed services from GCP, AWS and Azure can be configured and safely consumed using kubectl in standard pipelines (in Russian localization of GitLab “assembly lines”) GitLab or using Auto DevOps.

Using Crossplane together with Auto DevOps will give users the ability to manage cluster databases, providing a ready-to-release solution. Many thanks to the Upbound team for this great work!

Crossplane support in GitLab Managed Apps

Crossplane documentation and the original ticket .

Code intelligence with Sourcegraph

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Stage of the DevOps cycle: "Create"

Developers often use transitions to the definitions of variables and functions and look for relationships when writing software, but when reviewing code this is usually not available. Now, when viewing a code or a merge request review, a powerful code navigation from Sourcegraph has become available.

In the GitLab 12.5 release, once the instance administrator has configured the Sourcegraph integration, you can agree to use it in your settings. At GitLab.com, we are gradually adding Sourcegraph for public projects. You can try it right now in this GitLab project by including Sourcegraph in your user settings .

Thanks to Sourcegraph for making this integration ! Learn more about her .

Sourcegraph documentation and original ticket .

Environment Panel

(PREMIUM, ULTIMATE, SILVER, GOLD) Stage of the DevOps cycle: "Release"

GitLab environments are a logical structure that gives you control over the state of the physical environments in which your code is deployed. This is one of those features that make GitLab a truly CD solution, and not just a convenient CI tool for managing deployment. However, when there are many environments, it becomes difficult to manage them. Previously, tracking the status of several environments of different projects was difficult, since you had to move to each project to view its built-in environments.

The new panel of environments provides data on all environments among your projects, allowing you to see the whole picture of what is happening in each environment. Now you can track how changes are moving from development to staging, and then to production, or through any of your other environments, from one place. With a new convenient view of the environment of all projects, you can immediately see which pipelines completed successfully and which are not, understand where the block appeared, and if there are more systemic problems that require investigation. The environment panel will help you more effectively solve these problems.

Environments Dashboard

Documentation on the panel of environments and the original ticket .

Association of Milestones with Release

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Stage of the DevOps cycle: "Release"

Many teams, including ours, create a milestone for each release (in the Russian localization of GitLab, a “stage”), to which everything is attached, and for some teams, the release may include more than one sprint. Now you can associate one or several milestones with the release, and the release page will be filled with all the tickets and merge requests included in the release.

Associate milestones with a release

Documentation on releases and milestones and the original ticket .

Other improvements in GitLab 12.5

Event Audit APIs for Groups

(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) Stage of the DevOps cycle: "Manage"

The Event Audit API provides insight into the state of your GitLab environment. Previously, only administrators could use this API to view instance events . Since GitLab.com users do not have this access, it was necessary to extend this functionality to group owners.

So we’ve made it possible to access group event data through the GitLab API to help you communicate your decisions and manage compliance in your groups. We plan to make the audit of events more detailed , and the API will also provide more useful information.

Event audit API documentation for groups and an original ticket .

Epics can now inherit start and end dates from their nested epics

(ULTIMATE, GOLD) Stage of the DevOps cycle: "Plan"

In this release, we made it easier to work with information about the timing of your epics (in the Russian localization of GitLab, “goals”). Now epics can inherit the start and end dates of milestones not only from attached tasks, but also from attached nested epics. No longer have to guess at what timeframe the attached epics and tasks should be completed.

Documentation of start and end dates in epics and original ticket .

Improved navigation on the pages of the group, subgroup and project

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Stage of the DevOps cycle: "Plan"

If you have a complex structure of groups, subgroups and projects, it may be difficult to understand exactly where you are in the hierarchy. Now, thanks to the updated look of the left navigation bar, you can quickly understand what context you are working in.

Documentation on the creation of projects and the original ticket .

Design annotations are displayed in ticket activity

(PREMIUM, ULTIMATE, SILVER, GOLD) Stage of the DevOps cycle: "Create"

Previously, when adding a new annotation or comment to a design, this was displayed only in the design itself. Now, when adding new annotations, GitLab will also add a mention of this on the Discussion tab so that everyone involved in the task will know about it. Thus, it will be easier to work on designs together and everyone will be able to contribute.

Design annotation documentation and original ticket .

Git info / refs caching (beta)

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Stage of the DevOps cycle: "Create"

Upon receiving changes to the git repository, the Git server announces a list of all branches and tags of the repository. In some instances, 75% of all requests to the web server were requests for links (refs). In the best case, when all links are packed, this is a relatively inexpensive operation, but if there are unpacked links, Git will have to get around them. And this can already lead to expenses due to additional operations on the disk, especially when using storage with high latencies, for example, NFS.

Starting with release 12.5, instance administrators can enable the beta info/refs cache to increase the performance of link declarations and reduce the load on Gitaly with frequent ad requests.

Testing this feature on GitLab.com, we have already found that read operations outnumber write operations by 10 times, and the apparent average delay decreased by 70%. We expect even better results for GitLab instances with NFS as a repository for Git.

By default, the cache is not yet enabled, as we are investigating a higher-than-expected demand for writing to the cache, probably caused by concurrent misses. Stay tuned for gitaly # 2124 .

Caching of Git info / refs (Beta)

Cache documentation and original ticket .

Mergeable status added to merge request API

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Stage of the DevOps cycle: "Create"

The merge request API now includes more details on why the merge request cannot be accepted. The has_conflicts attribute indicates whether there were merge conflicts, and the blocking_discussions_resolved attribute indicates whether there were unresolved discussions. These new attributes are especially useful for automation, as they show what actions are needed to resolve conflicts.

Thanks to Brian Kabiro for this feature !

Documentation on obtaining information about merge request and the original ticket .

Passing values to `pipelines/new` page via query string

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Stage of the DevOps cycle: "Verify"

To create a new pipeline through the GitLab website, go to the /pipelines/new page and fill in the required values to start the pipeline. Previously, it was already possible to add the ref parameter to select a branch or tag (for example, /pipelines/new?ref=master ). Now we have added the ability to similarly set other values through the query string.

Documentation on the use of the query string and the original ticket .

Custom script aliases in gitlab-ci.yml

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Stage of the DevOps cycle: "Verify"

Creating small “building blocks” that can be used repeatedly is a powerful tool in the design of conveyors. This will allow you to avoid repetition, separate functions into separate understandable blocks and create chains of dependencies in which the code block is updated simultaneously for all dependent blocks.

GitLab has several mechanisms for applying this pattern in design, including default YAML syntax elements such as anchors and aliases. However, when you try to use an array of aliases with the keywords script , before_script or after_script , a nested array is created during the merge, which will not work.

In GitLab 12.5, script arrays work correctly when accessed through anchors. Using them with include and extends still fails, but you can use anchors inside a separate file to access an array of new design patterns.

Documentation for anchors for scripts and the original ticket .

Display details on JUnit errors in merge request

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Stage of the DevOps cycle: "Verify"

Prior to this release, the user received information about when the tests were unsuccessful, but without the data necessary to resolve the problem and quickly create a successful assembly. Starting with this release, GitLab will display on the pipeline data about the results of passing the JUnit test.

This includes the results of passed, missed and failed tests, as well as timing and a detailed overview of individual tests, including a list of those that failed, for faster identification and resolution of problems.

Display JUnit error details in merge request

Documentation on the results of Junit tests and the original ticket .

Contextual documentation to help users download NPM packages

(PREMIUM, ULTIMATE, SILVER, GOLD) Stage of the DevOps cycle: "Package"

From a recent user survey, we learned that the main reason users switch to the package registry UI is because they need to make sure that they are using the correct version of the package . One of the ways we can help with this is by providing snippets of code that are easy to copy to download and install individual packages.

In GitLab 12.5, we are pleased to introduce the first iteration to improve navigation and workflows in the GitLab package registry. Now users can easily copy the code to run npm install and npm setup to install the packages they need faster.

Contextual documentation to help users download NPM packages

NPM registry documentation and original ticket .

Public API for switchable features

(PREMIUM, ULTIMATE, SILVER, GOLD) Stage of the DevOps cycle: "Release"

We have added API functionality that will allow you to configure and manage switchable features. Previously, this could only be done through the UI.

API documentation for features and the original ticket .

CI-based Cluster Management

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) DevOps loop stage: "Configure"

The ability to install Kubernetes applications with one click is useful for quickly starting and getting started. However, it is sometimes necessary to configure the Helm chart before installation. A new approach to CI-based cluster management will allow users to create “cluster management projects” that receive cluster-admin privileges over the cluster and can interact with the cluster through CI. This will not only allow you to install template applications , but also give users the ability to customize charts before installation. Moreover, users will be able to use all existing GitLab features related to security, authentication, version control and CI when managing Kubernetes applications. In the future, we are going to combine one-click installations with CI-based application installations.

CI-based cluster application management

Cluster management documentation and the original ticket .

OpenFaas runtime support in GitLab Serverless

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) DevOps loop stage: "Configure"

GitLab Serverless now supports the classic OpenFaaS runtimes . With their help, developers can write serverless functions for Knative in one of six supported languages .

Supported runtime documentation and an original ticket .

Automatically close GitLab tickets when receiving recovery signals from Prometheus

(ULTIMATE, GOLD) Stage of the DevOps cycle: "Monitor"

GitLab incidents are resolved in one of two ways:

Someone is solving a problem.
The system itself fixes the problems.

After troubleshooting, the incident ticket should be closed so that there is no confusion about which incidents are active and which require elimination of the consequences. When an incident is resolved as a result of solving a problem, Prometheus generates a system recovery signal, giving GitLab the ability to automatically close the ticket associated with the incident.

This will save the incident resolution specialists from unnecessary manual work, and also ensures that every open ticket is an urgent problem that needs to be resolved.

Documentation on incident response and original ticket .

Filtering a Sentry Error List by Header in GitLab

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) DevOps loop stage: "Monitor"

Sorting errors requires the ability to filter and sort the error list based on user criteria that is suitable for a given case. You can now search the list of Sentry errors within the GitLab project through integration with Sentry. Just go to Operations> Error Tracking in the left pane to find and view Sentry errors.

Documentation on the list of errors and the original ticket .

Slack Commands to Add Ticket Comments

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) DevOps loop stage: "Monitor"

ChatOps allows you to start operations through intuitive commands and actions that you can enter directly in the chat. We expanded the existing Slack command set by adding a command that allows you to add a comment to a GitLab ticket without leaving Slack. This will allow you not to be distracted from work and not switch between multiple interfaces just to pass on a ticket to a team member or customer.

Documentation of the teams and the original ticket .

Editing the metrics panel

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) DevOps loop stage: "Monitor"

Previously, to create their own version of the control panel, users had to create a YAML file in the root directory of the repository and fill it out completely. This was quite complicated and required a lot of manual actions.

Now, in GitLab 12.5, this has become much easier. By clicking on the “Edit dashboard” button, you will be redirected to the IDE page where you can update the already created YAML file.

Edit Metrics Dashboard