Mar 22, 2020 - Larissa Lane  
12.9

GitLab 12.9 released with Vault App, Code Quality Reports and Group Deploy Tokens

GitLab 12.9 released with Secrets Management, Container Scanning Vulnerability Remediation, Customizable Cycle Analytics, Full Code Quality Reports, Group Deploy Tokens and much more!

GitLab 12.9 is now available to help DevOps leaders achieve enhanced security with management of your secrets via HashiCorp Vault managed application, better visibility with code quality reports & customizable value stream analytics, and easier administration with group deploy tokens and API administration of deploy tokens.

Secure your applications with Secrets Management and Vulnerability Remediation

Many organizations are centralizing the storage of secrets for infrastructure and applications in external secrets management solutions, including HashiCorp Vault. With GitLab 12.9, we enable users to leverage HashiCorp Vault to securely manage keys, tokens, and other secrets at the project level by installing it as a managed application within a Kubernetes Cluster. For current HashiCorp Vault users, you can follow our Bring Your Own Vault Integration progress in gitlab&2868.

When Container Scanning detects vulnerabilities, GitLab 12.9 can now give a suggested solution for the vulnerability, when available. You can choose to remediate the vulnerability with a merge request, which will automatically update the packages in the container base image, helping you resolve container security issues swiftly and efficiently.

Better visibility with Customizable Value Stream Analytics and Code Quality Reports

Value Stream Analytics helps organizations visualize their end-to-end workstream and identify inefficiencies, in order to continuously improve how they deliver value. Previously the lifecycle stages were fixed to the DevOps loop, which may not be suitable for everyone, as some teams may follow a different workflow. With GitLab 12.9, you have more control to customize the stages to reflect the right metrics for your business. Each new stage can have specific trigger events that define the entry or exit of the stage, allowing you to focus on improvements based on your defined key performance indicators. Be on the lookout for more capabilities in our upcoming releases.

Previously, developers used the Code Quality feature in the merge request to understand the impact on quality of the target branch. However, this does not give insight to developers and managers into other code quality issues across the project. With GitLab 12.9, we have introduced a Full Code Quality Report that summarizes the quality issues across the project.

Improve efficiencies with Group Deploy Tokens

For any organization working with containers, it is critical for their orchestrator to have secure and ongoing access to their container registry. Previously, we introduced Project Deploy Tokens to provide long lived read-only authentication to the registry without being associated with a particular user or having unnecessary access rights.

With GitLab 12.9, managing deploy tokens in bulk is now more efficient, as we are not only introducing deploy tokens at the group level but also APIs to create, list and revoke deploy tokens. If a specific project requires to use different tokens, project-level deploy tokens override group level deploy tokens.

And much more!

There are so many great features in GitLab 12.9, that we couldn't possibly highlight them all. A few favorites include WAF Statistics Report, Group level Roadmaps now available in Premium, and Log Aggregation now available in Core! Keep reading below to get details on every feature release.

Provide feedback on this release post Join us for an upcoming event

GitLab MVP badge

This month's Most Valuable Person (MVP) is Steve Exley

Steve contributed one of the biggest architectural changes to the Docker executor. These changes will create a network per build, which solves multiple issues for the Docker executor, including jobs sharing the same network bridge, services don’t work when network_mode is specified, and lastly, services can connect to one another and connect with the build container as well!

Steve worked on this throughout multiple releases and picked up the work from the original contributor, Michael. Steve was humble and responsive to every comment we left in the merge request which turned out to be a long one!

Check out Network per build, and get started today! Thank you, Steve, for your contribution and hard work.

Key features released in GitLab 12.9


Select and dismiss multiple vulnerabilities

Our security dashboards provide quick insight and visibility of potential vulnerabilities detected by our various Secure scanners. Engineering and security team members can quickly review, triage, and create issues for remediating vulnerabilities. Sometimes, vulnerabilities do not need to have further action taken and can be dismissed. For projects with multiple such findings, dismissing each individually can be time consuming.

We’re excited to announce new functionality on the security dashboards that improves the efficiency of vulnerability management. You can now quickly select multiple vulnerability findings and dismiss them all at once.

From a pipeline, project, group, or instance security dashboard, select all vulnerabilities on the screen with a single click or choose specific ones to then dismiss with a pre-set reason. For even faster triaging, use the existing dashboard filters to look at only specific vulnerability types where dismissable findings are likely to appear.

Select and dismiss multiple vulnerabilities

HashiCorp Vault GitLab CI/CD Managed Application

GitLab wants to make it easy for users to have modern secrets management. We are now offering users the ability to install Vault within a Kubernetes cluster as part of the GitLab CI managed application process. This will support the secure management of keys, tokens, and other secrets at the project level in a Helm chart installation.

HashiCorp Vault GitLab CI/CD Managed Application

Group Deploy Tokens

GitLab already supports project-level deploy tokens. Now, we’ve added support for deploy tokens at the group level to make it easier to configure groups of projects. This will make sharing secrets between projects much more convenient and help in use cases such as: users deploying many projects to one Kubernetes cluster where different secrets need to be created per project. Creating a group level token allows users to set one shared secret for the entire cluster.


Release Progress View

GitLab Releases are a one stop place for all the contents of a release. With the new Release Progress View introduced in GitLab 12.9, you will be able to easily answer the questions many release and build managers are spending time manually collecting. In a single look on the Release page, you can see the number of open, closed, and in-progress public issues that are associated with the milestones of the Release. A convenient percentage progress bar will also give you a quick update on how your release is progressing.

Release Progress View

Dynamic child pipelines

Beginning with this release, child pipelines can now be started using a dynamically generated .gitlab-ci.yml. Using this approach, you can generate child pipelines that reflect runtime analysis of what’s changed or other criteria (for example, to build a matrix of targets and architectures).

This addition will open up a whole new set of use cases for this feature, while helping keep configuration simple. We can’t wait to see what you build with it!


GitLab CI/CD template for deploying to ECS

Many users want to deploy to AWS using GitLab CI/CD. In order to help deploy to Elastic Container Service (ECS), we have created a template that shows you how to get started.

Users can include the template in their configuration, specify a few variables, and their application will be deployed and ready to go in no time.

GitLab CI/CD template for deploying to ECS

Skip outdated deployment jobs

Before GitLab 12.9, users trying to roll out a pipeline could encounter a situation where an older and delayed pipeline would deploy after a newer deployment and override it. Now, forward deployments provide the option to ensure that when a pipeline runs, it is verified to be the most recent deployment and makes sure that an older pipeline doesn’t override a newer one.

Skip outdated deployment jobs

Web Application Firewall (WAF) Controls

We’re pleased to announce new controls to manage your Web Application Firewall (WAF)! You can now easily turn your WAF on or off globally on your project’s Operations -> Kubernetes page.

Web Application Firewall (WAF) Controls

Web Application Firewall (WAF) Statistics Reporting

We’re pleased to announce WAF Statistics Reporting! You can now see data on both total and blocked traffic, allowing you to more easily determine how to configure, tune, and evaluate the Web Application Firewall.

WAF statistics will appear on a new Threat Monitoring page under the Security & Compliance menu item. By default, this data covers a 30 day period.

Web Application Firewall (WAF) Statistics Reporting

Dynamic environments support for Review Apps

Review apps currently require a static URL to be used as the CI/CD variable CI_ENVIRONMENT_SLUG. In many use cases, though, this environment variable is dynamic instead of static. For example, when using AWS, a user may want to use the environment name based on the stage, which may not be known before the deployment.

In 12.9, we’ve introduced a new report artifact, dotenv. The artifact can be passed between jobs, providing truly dynamic URL support for Review Apps. This unlocks the ability to use Review Apps in dynamic environments, such as native cloud deployments.


Group-level Roadmap now available in Premium!

Previously in Ultimate, group-level Roadmaps are now available for Premium! Tracking the state of your work is key to delivering value on time. Visualize your epics across a timeline and see when they are scheduled to be completed.

Group-level Roadmap now available in Premium!

View epic progress by weight completed on your roadmaps

Knowing the status of work in flight is critical. Our Roadmap now helps you visualize progress by displaying the percentage of weight completed via a progress bar on displayed epics. Keep up to date with your critical projects and efforts with ease!

View epic progress by weight completed on your roadmaps

High Availability for Gitaly (alpha)

For many customers, GitLab is a business critical application because an outage would prevent developers from being productive, and obstruct the deployment of new features and fixes. To prevent outages, GitLab can be run in a highly available (HA) configuration. The currently documented HA configuration recommends using NFS. However, NFS significantly increases the latency of read and write operations, which severely impacts the performance of Git operations, particularly as the size of the repository grows.

Gitaly now offers experimental alpha support for high availability without using NFS. This feature should not be used in production! There are single points of failure, and unexpected data loss may occur. However, you may wish to start evaluating high availability for Gitaly in a test environment. Since January, we have successfully been testing on GitLab.com with a small number of projects.

High Availability for Gitaly is eventually consistent, implemented as an asynchronous replication queue, favoring availability over consistency. If an outage occurs on a primary Gitaly node before the replication queue has been drained, data loss will occur. In parallel we have begun investigating strong consistency to prevent such data loss scenarios.

High Availability for Gitaly (alpha)

Other improvements in GitLab 12.9

Additional audit events

Compliance-minded organizations need visibility into the actions of their users. This can help identify anomalous activity, mitigate risks, take action on certain behaviors, and document activity for regulatory compliance. We’re continuing our work on the Audit Events category, striving to capture 100% of user-driven events, to support the organizations relying on GitLab for auditability and traceability of their GitLab user activity.

GitLab 12.9 now provides audit events for the following changes made to merge request approval settings: prevent approval of merge requests by merge request author, prevent approval of merge requests by merge request committers, and number of required approvals. These events are visible under the project-level and instance-level audit events tables.

Group Export and Import is available using the API

Migrations between GitLab instances can be challenging, especially from self-managed GitLab to GitLab.com, because organizations can have their work organized in many Projects and Groups. Until now, these migrations had to be done by exporting and importing one Project at a time.

With the release of the Group Export/Import MVC, users can export an entire Group and easily import it into the desired instance of GitLab, whether their destination is GitLab.com or another self-managed GitLab instance.

View history of changes to issue, merge request and epic descriptions

The descriptions of issues, merge requests, and epics can be freely edited as they naturally evolve. In the past, changes were not recorded and the history of these descriptions was lost. Not any more! GitLab now stores these updates, and allows you to view what changes were made, who made them, and when!

Drag-and-drop support for uploading Designs

Up until this release, the only way to upload Designs to GitLab was to click and use the file uploader. This worked but is not as efficient as using drag-and-drop. With this release you can now do the following in the Designs tab:

  • Upload a new Design by dragging a new file and dropping into the dropzone.
  • Upload a new version of an existing Design by dragging a new file with the same name and dropping into the existing Design.
Drag-and-drop support for uploading Designs

GitLab hosted CodeSandbox for Client-Side Live Preview

In GitLab 11.2 we released live preview powered by CodeSandbox to allow you to preview simple Javascript apps and static sites in the Web IDE. This feature depends on scripts hosted by CodeSandbox, but due to security concerns around sending private code to a third party, some customers were not comfortable using this feature.

GitLab.com is now hosting the required package to enable live preview in the Web IDE. This is the first step in enabling this feature across self-managed instances of GitLab. In a future release, we’ll provide a configuration option for self-managed instances to host the required libraries themselves, and we’ll also look into enabling it by default for all GitLab instances.

Reduce email notifications for eligible approvers

Email notifications allow you to keep up with issues and merge requests you’re interested in from your inbox. GitLab provides various levels of notifications, including Participate, which notifies you of activity after you’ve participated in the merge request or issue. However, people who have been configured as eligible Merge Request Approvers, would receive notifications for all activity on every merge request for which they are an eligible approver. This made the number of email notifications overwhelming for all but the smallest projects.

From GitLab 12.9, eligible approvers are no longer treated as participants until they leave comments, or approve the merge request. This will reduce the volume of emails being sent to eligible approvers, so they can focus on the notifications that matter. If you want to receive more emails, the Watch setting will notify you of any activity on the project.

White syntax highlighting theme for Web IDE

Users have strong preferences for consistency in the tools they use which is why GitLab has long supported alternative syntax highlighting themes. The white theme is the most popular across GitLab, however, our code editor areas have been inconsistent in applying a matching theme.

The Web IDE is now consistent with the White syntax highlighting preference in the repository and diff areas of GitLab. We’ll continue to expand our support for syntax highlighting preferences in the Web IDE. We’re also continuing to extend the dark theme, introduced in GitLab 12.8, to the rest of the Web IDE, including the file tree and sidebars.

White syntax highlighting theme for Web IDE

Disable inheritance of defaults and variables

Previously, users had the ability to set certain parameters as global defaults for all of their jobs by using the default: keyword. However, disabling these defaults for a particular job required manually overwriting each setting and was inefficient. Additionally, it wasn’t possible to prevent the inheritance of variables once they were defined as global defaults.

In GitLab 12.9, we’ve now added the ability to disable the inheritance of globally defined defaults and variables. Using the inherit: parameter, users can explicitly define what is inherited from the global defaults and more easily define a job’s behavior.

Improved performance for the GitLab Container Registry garbage collection algorithm for Google Cloud Storage (GCS)

Our users have expressed frustration about the long downtime that is needed to run garbage collection on old, unused images, and we’ve heard you. The improvements we’ve made to the efficiency of the cleanup code means you don’t have to make a tradeoff between two bad options: taking a long outage, or keeping around lots of unneeded files.

In GitLab 12.9, we are excited to announce a significant improvement in the performance of garbage collection for instances using the GitLab Container Registry and leveraging GCS for storage. While testing with a 1.4GiB repository, which is a rough approximation of the 10 TiB registry used on dev.gitlab.org, we observed a performance improvement of 95%.

Use npmjs.org as a default remote repository when the package is not found in the GitLab NPM Registry

The GitLab NPM Registry allows users to host a private NPM registry alongside their source code and pipelines. This works best if the GitLab NPM Registry is the only source of packages with the GitLab group_name scope. However, it’s common that users also publish open source packages to the global NPM registry using the same scope, often when their private packages depend on those public packages.

In GitLab 12.9, we are excited to announce that you can now use https://www.npmjs.com/ as a remote repository when the package is not found in your GitLab private registry. This feature will be auto-enabled at the instance level and can easily be disabled by navigating to the instance level CI/CD settings.

Flag outdated security reports in the Merge Request

Previously, it was impossible to tell from the merge request view whether the security report for the branch was out of date. This was only solvable by manually comparing the security report in the merge request to the security report on the master branch. The merge request will now show that the security report for the selected branch is outdated if the source branch is behind the target branch in commits. Guidance is offered to bring it up to date.

Suggested solution for Container Scanning

When Container Scanning finds a known vulnerability for your base image, GitLab offers a suggested solution (upgrading to the next version of the vulnerable package) where applicable. Users must select Resolve with merge request and submit the merge request that is generated with the proposed solution. This helps you swiftly and efficiently respond to and resolve container-based security findings while reducing your security risk and compliance risk. Please provide feedback for desired improvements in this epic.

Updated documentation to include steps to run offline SAST for self-hosted instances

We have enhanced our documentation to better describe how to run SAST scans in a self-hosted, offline GitLab environment.

This will allow you to improve your project’s security, while still being in compliance when running GitLab in an offline environment.

Deploy keys and Deploy tokens move to CI/CD settings

Deploy keys and Deploy tokens have found a new home under Settings > CI/CD. They were previously found under Settings > Repository and were more difficult for users to find. Since both are used for CI/CD purposes, we consolidated all settings into this location.

Install Crossplane application using GitLab CI/CD

Installing Kubernetes applications using GitLab CI/CD provides a great way to customize GitLab Managed Applications prior to installation. As part of this release, we have added a template for installing Crossplane using GitLab CI/CD. Installing the Crossplane chart via GitLab CI/CD allows users to specify any and all Crossplane chart configuration options.

Drill down from incident to log explorer

Previously, users struggled to find relevant logs when troubleshooting incidents. Starting with 12.9, users can drill directly down from the incident to the log explorer while preserving the same timeframe, simplifying investigation of the incident and finding the root cause.

Drill down from incident to log explorer

Filter error list by status

Digging through a large list of errors to find the important ones that are impacting users can be a challenge when there is a low signal to noise ratio. You can now filter the list view of Sentry errors in GitLab by error status (ignored, resolved, or unresolved) to remove the cruft and focus on the problems you actually need to fix.

Filter error list by status

Log aggregation in Core

As a part of our 2020 gift, we’ve decided to move the log aggregation capabilities in the monitor stage from GitLab Ultimate to GitLab Core. This means that starting with GitLab 12.9, all users will be able to view their Kubernetes based application logs within the GitLab UI.

Support pagination in log explorer

Previously, the Log explorer would show only 500 lines on the console - limiting a user’s ability to view logs when triaging an incident. With the support for pagination, users can select any time frame they like and scroll infinitely to view an unlimited amount of log lines.

Support pagination in log explorer

Fixes for Geo database timeouts when finding unsynced Git LFS objects

Geo compares the tracking database to the read-only secondary database to determine what needs to be synced. The existing design has been iterated on and optimized, and we keep improving it further. If Geo’s database queries time out, data can’t be replicated successfully. In GitLab 12.9, we use a new approach to sync Git LFS files which eliminates the possibility of database statement timeouts. This design will be rolled out to other data types after we have validated the solution.

In addition, this sets the stage to allow Geo to remove its dependency on Foreign Data Wrappers, which was added for improved performance, but makes Geo more complex and harder to maintain.

Omnibus improvements

  • Upgrading PostgreSQL on Geo secondaries just got easier. pg-upgrade now supports upgrading PostgreSQL on Geo tracking database nodes. Previously, upgrading the Geo tracking database required the postgresql['enable'] setting to be temporarily set to true in thegitlab.rb file. Now, simply run the pg-upgrade command on the tracking database node.
  • It is now possible to provide a default statement timeout when using an external PostgreSQL database. Previously this could only be set when using the bundled PostgreSQL database. The statement timeout is used to automatically kill queries that run for longer than the specified time. For details on configuring the timeout, see the database settings page
  • GitLab 12.9 includes Mattermost 5.20, an open source Slack-alternative whose newest release includes a new mobile editor, desktop dark theme, and much more. This version also includes security updates. Upgrading from earlier versions is recommended.

We detected an issue where some additional changes need to be made to the configuration of the Geo tracking database after running pg-upgrade. A fix is planned for 12.10. For 12.9, we recommend using the old method of changing the gitlab.rb file.

Reduced memory consumption of GitLab with Puma

GitLab is switching application servers from Unicorn to Puma, reducing the memory footprint of GitLab by 40%. This improved efficiency can allow GitLab administrators to leverage smaller memory instances, reducing the operational costs of the service. These savings are achieved due to leveraging the multi-threading support in Puma, compared to the single-threaded model of Unicorn.

Puma support is generally available in Omnibus, and experimental in the Helm chart. We plan to make Puma the default application server in GitLab 13.0.

Customizable Value Stream analytics

Value Stream Analytics allows teams to understand the behavior of their development process by providing key metrics related to the planning, development, review, testing and production release of their software process. Now in 12.9, GitLab users have more control over the measures used to reflect their process. For each lifecycle stage, team leads may define trigger events which define when an issue or MR is considered to have entered or exited the stage. With this new flexibility, teams will be able to reflect their own processes in GitLab with higher fidelity and make decisions about where to focus improvement activities on the basis of their team’s historical data.

Customizable Value Stream analytics

Filter issue list by an Epic

You can now filter an issue list by Epics. Quickly pull up a list of issues assigned to an epic, review, and interact with them in bulk to assign additional labels or milestones.

Filter issue list by an Epic

Commit all changes in the Web IDE

In GitLab 12.7 we began automatically staging all changes in the Web IDE as a step towards better accessibility by more personas. This measure also helped to prevent accidental loss if all changes weren’t properly staged prior to leaving the Web IDE.

This was an important change in Web IDE workflows and now, we’ve made this even easier by removing the staging workflow completely from the Web IDE. Now when a user makes a change in the Web IDE they won’t need to decide to stage or unstage their changes for their commit. They’ll see a new Changes tab that has a list of all changed files. This is a valuable step in making git and GitLab more accessible to users in the Web IDE.

Commit all changes in the Web IDE

Enable Git protocol v2 for SSH

We’ve re-enabled support for Git protocol v2 over SSH. In the previous release, GitLab 12.8, we re-enabled support for Git protocol v2 over HTTP. It was previously announced in GitLab 11.4, but was disabled due to a security issue in Git versions before Git 2.21.

Developers fetch refs many times a day to check if the current branch is behind the remote branch. Previously, all responses to fetch commands included a list of all references in the repository. For example, fetching updates for a single branch (e.g. git fetch origin master) would also retrieve a complete list of all references. In the case of large projects, this could be over 100,000 refs and tens of megabytes of data. Now, only the needed refs are transferred.

Git protocol v2 is a major update to Git’s wire protocol which defines how clones, fetches, and pushes are communicated between the client (your computer) and the server (GitLab). The new wire protocol improves the performance of fetch commands and enables future protocol improvements.

Git protocol v2 is enabled by default from Git 2.26, and available from Git 2.18 by running git config --global protocol.version 2.

HTTP push mirroring API

Push mirroring allows you to automatically push updates from your Git repository to copies stored elsewhere. Mirroring is easily configured from the project settings, but if it needs to be configured for hundreds of projects this is impractical. The new Remote Mirrors API solves this by allowing push mirroring over HTTP to be configured using the API.

Thank you Rajendra Kadam for your contribution!

Special markdown rendering for Design URLs

Sharing a link to the Design tab is an important part of collaboration and how users can surface Designs in comments or descriptions. Currently, when sharing a link to the Design tab in markdown, the link is long and unruly: https://gitlab.com/gitlab-org/gitlab/-/issues/12345/designs.

With this release, GitLab renders these links in a readable way so it’s easy to distinguish Designs in issue descriptions or comments: #12345 (designs). Now it’s easier for collaborators to spot when a user is referring to Designs rather than just linking out to an issue.

Zooming Designs now supports full width for long images

When a website layout is uploaded as a Design on an issue, they are often quite tall in size. This aspect ratio is frequently used for website layouts where there is a lot of content and the user has to scroll down. With this release, you will now be able to zoom in on longer designs so you can more easily see and comment on the Design at 100% width.

Full Code Quality Report

Users are already making great use of the code quality feature in Merge Requests to prevent code quality from slipping after making a single change, but this may not give enough insight into other issues within the project. Contributors now gain visibility into other code quality issues in order to resolve them in the current Merge Request or in a future change.

To better enable users to write high quality code, the full Code Quality report output is now available in the CI/CD pipelines and as a downloadable artifact. This change allows developers even more visibility into any code quality issues in their project within the GitLab UI.

Full Code Quality Report

List Changed Pages in the Visual Review widget

It can be difficult to navigate to a changed page in a Review App, especially in a statically generated site. Review Apps and Visual Reviews make it easy to leave comments directly in a Merge Request while looking at the modified page. That is, once you find it.

Starting in GitLab 12.9, users of Visual Review tools will be able to use a drop down list to navigate directly to the page(s) modified in a Merge Request, making it easier to find the changed page(s) and provide feedback on a Merge Request.

List Changed Pages in the Visual Review widget

Specify Docker images that should not be deleted as part of the Container Registry bulk delete API

For organizations with many groups and projects, it is more efficient to remove old, unused, Docker images by utilizing the bulk tag deletion API. However, there’s currently no easy way to express something such as “no matter what, don’t delete this tag.” This introduces risk into the deletion process since it’s possible to delete release or master images.

In 12.9, we are excited to announce that you can add the name_regex_keep attribute to the bulk delete API in order to prevent any tags that match the provided regex from being deleted. Now, you have an easier way to prevent your important images from ever being deleted!

Use the GitLab API for creating and revoking project and group deploy tokens

Deploy tokens allow users to fetch a project repository (through SSH with git clone) or to fetch the Container Registry images of a project without providing a username and a password. This enables users to create a single token for their project and avoid using personal access tokens. However, for organizations with many groups, sub-groups, and projects, it is inefficient and difficult to create deploy tokens for each project. Maintainers or administrators need a way to easily create and revoke deploy tokens for many groups and projects.

In GitLab 12.9, we are excited to announce that we have extended the Gitlab API to allow users to create, list, and revoke GitLab Deploy Tokens at the group/sub-group/project level. This will make the process of creating and managing deploy tokens much easier and safer.

New Policies tab under License Compliance

Previously, developers could only view license policies for newly added licenses in a merge request. With GitLab 12.9, all participants can now easily view a list of all licenses detected in a project, as well as a list of all of the License Policies that have been configured for the project. Developers will now easily be able to proactively verify if a license will be permitted in the project. This new view also allows maintainers to add or edit licenses policies from within the new tab.

Support SAST in networks with a custom Certificate Authority

GitLab instances can now leverage SAST scans on environments with custom Certificate Authorities. This allows advanced network configurations such as leveraging self-signed certificates or custom Certification Authorities to enable use cases like HTTPS traffic observation and monitoring.

Create a Release from the UI

GitLab now offers users the ability to create Releases from the UI. Users are a click away from creating a tag that contains all the contents of your Release version, including Release notes, milestone associations, and links added from the API stored as assets. This addition will make things easier for release managers who are planning releases for teams straight from the Releases page, rather than going to the Tags view.

Create a Release from the UI

Track cherry-picked commits from Merge Request

It is important to track everything that gets delivered to production. We now record when a merge commit is cherry-picked into a branch that gets deployed (when done either through the UI or through the API). The original merge request thread is updated with a system note indicating that the merge commit was cherry-picked into the deployed branch, and it is also included in the list of deployed merge requests.

Track cherry-picked commits from Merge Request

Automatically embed metrics in issue for all gitlab-configured alerts

GitLab Incident Management can create issues automatically when the Prometheus alert is triggered. Metrics charts help to visualize what anomaly caused the alert. Previously, charts could be embedded into the issue description, but this required manually grabbing the chart URL and pasting it into the issue.

Now, as of 12.9, a chart visualization for the metric that exceeded the threshold is automatically embedded in the issue description. This visualization saves you time in a firefight. You get critical information right away, without needing to go to an external source and perform a manual setup.

Note: This new capability will only work for alerts configured from the Metrics Dashboard within GitLab. In a future iteration, we plan to enable automatic charts for all Prometheus alerts regardless of how they are set up.

Edit custom metrics from charts

With the 12.9 release, we are improving the user experience to edit a custom metric directly in the metric chart rather than navigating to the Prometheus settings to edit the metric.

Edit custom metrics from charts

Formatting of y axis in metric charts

To improve visualization of the units on the y-axis and surface accurate data, we have introduced support for formatting the y-axis on the metrics chart.

Formatting of y axis in metric charts

Support additional query variables in custom dashboards

Custom dashboards can be created and configured using Prometheus queries. To allow users to create dashboard definitions that can be used across different projects, we have extended support to include additional CI variables in Prometheus queries.

View all pod logs from a single page

In a cloud-native world, logs are distributed across multiple pods. Previously, users would have to select each pod separately to view its logs, which can be challenging as pods can scale up significantly. In 12.9, we have added the ability to select “all pods” to help users troubleshoot incidents or verify the status of their services in a single view, instead of choosing each pod separately.

View all pod logs from a single page

GitLab chart improvements

Project-level code search now reliably responsive

Searching within a project for code is now reliably responsive, with most queries completing in under 250ms. In previous versions of GitLab, when Advanced Global Search was disabled, queries which generated a high number of results could see latencies of 10 seconds or more. This represents approximately a ten-fold improvement, improving the search experience for users.

This improvement affects both the GitLab UI as well as project blob search API.

Customers with self-managed instances should have a simple and stress-free process for adding and paying for users as they grow. Seat Link is our first step towards providing self-managed customers with more transparent, prorated charges for user growth throughout the year. Seat Link will enable GitLab to automatically charge a prorated amount each quarter for added users.

So how does it work? Seat Link sends to GitLab daily a count of all users in connected, self-managed instances, so we can automate prorated reconciliations and you never have to deal with true-ups again. Data will be sent securely through an encrypted connection.

Seat Link will send only the following information needed to automate prorated charges:

  • Date
  • Historical maximum user count
  • Active user count
  • License key

For air-gapped or closed network customers, we’ll continue with the existing true-up model. Seat Link is available in 12.9, but we will not start processing prorated charges until a future date, with a tentative target of 12.10.

For more details, see the recent blog post.

Deprecations

Auto DevOps' default PostgreSQL due to change

As part of updating Auto DevOps to support Kubernetes 1.16, we added the opt-in ability for Auto DevOps to use the PostgreSQL chart version 8.2.1 in GitLab 12.9. The default PostgreSQL chart version is currently 0.7.1. In GitLab 13.0, we plan to switch the default PostgreSQL chart version from 0.7.1 to 8.2.1. To remain on the old default, you will need to explicitly set the AUTO_DEVOPS_POSTGRES_CHANNEL CI variable to 1. To migrate your existing 0.7.1 PostgreSQL database to the newer 8.2.1-based database, follow the upgrade guide in order to backup your database, install the new version of PostgreSQL, and restore your database.

Deprecation date: May 22, 2020

DAST legacy entry points are being deprecated

As we now support using the /analyze entry point in DAST configurations, the /zap/zap-baseline.py, /zap/zap-full-scan.py, and /zap/zap-api-scan.py entry points will be deprecated as of 13.0.

Any configurations calling these entry points will break after GitLab 13.0 is released. We recommend that all our customers update their configurations to use the /analyze entry point to avoid any disruption in DAST scanning.

Deprecation date: GitLab 13.0

Ending support for Internet Explorer 11

With GitLab 13.0 (May 2020) we are removing official support for Internet Explorer 11. Please refer to our list of supported web browsers. You can provide feedback on this issue or via your usual support channels.

Deprecation date: May 22, 2020

GPG signing keys for GitLab package repository are expiring

The GPG signing keys for the GitLab PackageCloud repository are expiring and will be renewed in the first week of April. This means existing users who had already configured GitLab package repositories on their machines to be used via apt, yum or zypper, will have to fetch and add the new keys to continue installing or updating packages from the GitLab package repository. For detailed instructions, see the Package Signatures documentation.

Deprecation date: April 5, 2020

GitLab Snippets content search removal in 13.0

As we continue to work towards version control for Snippets we’ll be making a change to search for Snippets in the UI and API that removes snippet content from search results. Title and Description content will be accessible via search and API.

Deprecation date: May 22, 2020.

Offset pagination limit of 50,000 for /projects endpoint

An offset-based pagination limit of 50,000 will be applied on GitLab.com, and by default on self-managed instances, to the /projects API endpoint in GitLab 13.0. Integrations which make API calls with offsets above 50,000 will need to switch to a keyset-based pagination method, which will offer significantly improved response times and reduced load on the GitLab server. Self-managed instances will be able to customize the limit to a desired value.

To provide the optimized performance, keyset-based pagination only offers ordering based on project id. Use cases which require more flexible ordering options can continue to use offset-based pagination, provided the offsets remain below the limit. If use cases require flexible ordering options with deep offsets, we recommend sorting client-side.

Deprecation date: May 22, 2020

Planned removal of Docker in Docker (DinD) for Security Scanners in upcoming 13.0 Release

GitLab Secure scanners are moving away from using Docker in Docker (DinD) to increase the security and reduce complexity of scans. GitLab security products will begin to use non-DinD mode by default in vendored templates as soon as 13.0. We encourage customers to update their vendored templates to test out this new behavior. The documentation below details how you can try this today. In a future release after 13.0 we intend to remove DinD completely. Please be aware of slight changes in scanner detection logic, which are being addressed leading up to 13.0.

Deprecation date: May 22, 2020

Planned removal of PostgreSQL 9.6 and 10.x in GitLab 13.0

To take advantage of improved performance and functionality in PostgreSQL 11, such as partitioning, we plan to require PostgreSQL 11 in GitLab 13.0. PostgreSQL 11 was added in Omnibus GitLab 12.8. It will become the default PostgreSQL version in GitLab 12.10. While PostgreSQL 9.6 and 10.x are still supported and bundled in Omnibus GitLab, they will be removed in GitLab 13.0.

By requiring a minimum version of PostgreSQL 11, we can use its new features without the overhead of maintaining multiple code paths. Going forward, we will maintain a yearly cadence of PostgreSQL upgrades, with the minimum required version of PostgreSQL being no more than two versions behind the latest. We welcome your feedback on the proposed removals in the Move to PostgreSQL 11 and 12 epic. To start using PostgreSQL 11 now, see the upgrade docs.

Deprecation date: May 22, 2020

Planned removal of x-y-stable docker images in favor of Semantic Versions for Security Products

GitLab Secure tools have historically leveraged an x-y-stable docker tag to tie the scanners to the release version of GitLab. We are moving to publish docker images matching semantic versions of our tools (Major.minor.patch). Semantic versioning provides a number of benefits, which include:

  • The Docker image version will match the version in each analyzer’s CHANGELOG, so it’s easier to understand what features come with a specific version of the analyzer.
  • Users can choose their level of stability: no changes (pin to major.minor.patch), patch fixes only (pin to major.minor), new features and patch fixes (pin to major), bleeding edge (pin to edge).

We will continue releasing x-y-stable docker images until we officially drop support for them as early as %13.0. To prevent the failure of Secure scan jobs with customized vendored templates after this transition, users can follow this issue for details on how to update/migrate existing templates.

Deprecation date: May 22, 2020

Puma will become the default application server

GitLab will be switching default application servers from Unicorn to Puma in 13.0. Puma is a multithreaded application server, allowing GitLab to reduce it’s memory consumption by about 40%.

As part of the GitLab 13.0 upgrade, users who have customized Unicorn settings will need to manually migrate these settings to Puma. It will also be possible to remain on Unicorn, by disabling Puma and re-enabling Unicorn until Unicorn support is removed in a future release.

Deprecation date: May 22, 2020

Important notes on upgrading to GitLab 12.9

  • GitLab 12.9 includes Mattermost 5.20. For important upgrade notes on upgrading to this latest version of Mattermost, see Important Upgrade Notes.
  • GitLab 12.9 has a new command for checking background migrations. This is important for zero-downtime upgrades. For details, see Updating GitLab.

Changelog

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

Installing

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

Updating

Check out our update page.

Questions?

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

GitLab Subscription Plans

GitLab is available in self-managed and cloud SaaS options.

Self-managed: Deploy on-premises or on your favorite cloud platform.

  • Core: For small teams, personal projects, or GitLab trials with unlimited time.
  • Starter: For co-located teams with few projects who need professional support.
  • Premium: For distributed teams who need advanced features, high availability, and 24/7 support.
  • Ultimate: For enterprises that want to align strategy and execution with enhanced security and compliance.

Cloud SaaS - GitLab.com: hosted, managed, and administered by GitLab with free and paid subscriptions for individuals and teams.

  • Free: Unlimited private repositories and unlimited collaborators on a project. Private projects get access to Free features, public projects get access to Gold features.
  • Bronze: For teams that need access to more advanced workflow features.
  • Silver: For teams that need more robust DevOps capabilities, compliance and faster support.
  • Gold: Great with many CI/CD jobs. Every public project gets the features of Gold for free irrespective of their plan.

Cover image licensed under Unsplash free license

Try all GitLab features - free for 30 days

GitLab is more than just source code management or CI/CD. It is a full software development lifecycle & DevOps tool in a single application.

Try GitLab Free
Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license

Try GitLab risk-free for 30 days.

No credit card required. Have questions? Contact us.

Gitlab x icon svg