Feb 22, 2021 - Andrew Thomas

GitLab 13.9 Release

GitLab 13.9 released with a Security Alert Dashboard and Maintenance Mode

GitLab 13.9 released with a Security Alert Dashboard, Maintenance Mode, and so much more!

GitLab 13.9 is now available to strengthen DevSecOps at scale, with a Security Alert Dashboard to triage high priority alerts, Maintenance Mode for unfailing support of distributed teams, better visibility including additional support for DORA metrics, and advanced automation capabilities that will help you deliver “better products, faster.” These are just a few of the 60+ significant new features and improvements in this release.

DevSecOps at scale

Keeping a production environment both secure and available are top priorities, but they can be difficult to balance. Our new Security Alert Dashboard will help you balance security and reliability, by discerning between suspicious network activity that needs to be blocked immediately or that only needs further attention, minimizing disruption to users. We're also excited to add JavaScript and Python support for coverage-guided fuzz testing, making it easier to build secure and reliable software, with results piped into your Security Dashboard.

GitLab is built for distributed teams. Our new Maintenance Mode enables read-only availability of your instance during more admin tasks, further reducing downtime. Scale and redundancy in data storage are improved with variable Gitaly replication factors, so you can tune your cluster to your own storage and budget constraints, while also enabling horizontal scaling.

Visibility is another core requirement in scaling DevOps, and Release Analytics at the group level continues to grow our support of DORA metrics, now aggregated for projects in a group. The new failed-test counter in Unit Test Reports and a new merge request metric, mean time to merge help you achieve and understand underlying efficiencies.

Automate your way to better products, faster

If you’re new to DevOps or renewing stalled efforts, an edict to deliver “better products, faster” can sound a little like “doing more, with less;” it may feel counterintuitive. But DevOps is the answer and automation is the key to doing both well.

One sure way to build and test faster is to look for redundancies in configuration. A new function in 13.9 saves you time by enabling reuse in your pipeline of a CI/CD configuration from any job, even if it's in another file.

Automating at scale often requires mitigating complexity. When you’ve broken down your pipeline configuration into many files, you’ll like that you can now view an expanded version of the configuration. Deployment processes using parent-child or multi-project pipelines can also now use resource groups to manage concurrency across stages, jobs, and even projects.

Wider community contribution highlights

We’re thrilled to introduce GPU and smart scheduling support for GitLab Runner, supporting specialized compute workloads like those in machine learning, and contributed by this month's MVP, Andreas Gravgaard Andersen! Andreas showed awesome perseverance through reviews that spanned 10 months.

Thanks to another brilliant contribution, you can now follow other GitLab users’ activity! You might start by following its contributor, Roger Meier @bufferoverflow from Siemens, himself a GitLab Hall of Famer and sage of Open Source and InnerSource.

Thank you to Marshall Cottrell @marshall007 from NASA for creating a 1-liner installer for the GitLab Agent for Kubernetes and simplifying its configuration, enabling users to get started with the Agent much more easily. Marshall's feedback, ideas, and collaboration beyond merged contributions were also called "invaluable."

Thank you to Kev @KevSlashNull of SiegeGG, who added an Activity filter to Vulnerability Reports, helping you drill into precisely the vulnerability list view you need. GitLab's own AppSec team are grateful as are many others, for this and Kev's many contributions.

GitLab isn't only a DevOps platform, or a company, we're also a community, and in 13.9 alone we enjoyed an incredible 299 merged wider community contributions. Selecting one MVP wasn't easy; thank you all for your professionalism and hard work.

And so much more!

Some of our favorite quality of life improvements in 13.9 include:

Create changelogs using the GitLab API
Mark changes as viewed in merge requests
Request a follow-up review from a Reviewer
Create Jira issues from Vulnerabilities
Assign incidents to milestones
Markdown links for Feature Flags
Allow Deploy Keys to push to protected branches

Read on for more, and to preview what's coming in next month’s release, check out our Upcoming Releases page and our 13.10 release kickoff video.

GitLab 13.9 released with a Security Alert Dashboard and Maintenance Mode Click to tweet!

Join us for The Total Economic Impact™ of GitLab

MVP This month's Most Valuable Person (MVP) is awarded to Andreas Gravgaard Andersen

In 13.9, Andreas added Graphical Processing Unit (GPU) support in GitLab Runner. This change enables you to train machine learning models, render animations, or offload other calculations. For more details, see the item below. This merge request finally landed for 13.9 thanks to Andreas’ persistence and responsiveness to many rounds of reviews spanning over 10 months. Thank you Andreas! 🙌

13.9 Key improvements released in GitLab 13.9

Security Alert Dashboard for Container Network Policy Alerts

Security Alert Dashboard for Container Network Policy Alerts

SaaS

Self-Managed

We’re pleased to announce the first release of a dashboard for security alerts! Users can now configure Container Network Policies to send alerts to the security alert dashboard. This is especially useful when traffic must be closely monitored but cannot be blocked entirely without negatively impacting the business. You can configure the alerts at Security & Compliance > Threat Management > Policies, and view them at Security & Compliance > Threat Management > Alerts.

Security Alert Dashboard for Container Network Policy Alerts

Documentation Issue

Maintenance Mode

Maintenance Mode

SaaS

Self-Managed

Systems administrators occasionally perform maintenance operations on their GitLab instance to keep it performing optimally. Administrators want to offer the highest level of access to their users while these operations are taking place. For example, you may want to perform a failover test to a secondary site as part of the company’s business continuity plan. Prior to the failover, you want to pause changes for a short period to ensure the secondary is fully synchronized. Until GitLab 13.8, you could restrict users from logging in, but this would block the entire UI and would render GitLab inaccessible to users.

GitLab 13.9 introduces maintenance mode, where write operations are disabled at the application level. This means that GitLab is effectively in a read-only state for all non-administrative users (administrators are still able to edit application settings and background jobs continue). Regular users are able to log in to GitLab, view the interface and perform other read-only operations, such as git clone or git pull. Using maintenance mode, systems administrators can perform maintenance operations, such as failing over to a secondary site, with minimal disruption to regular users.

Note that GitLab already supports zero-downtime updates and enabling maintenance mode is not required to keep your instance up-to-date.

Documentation Epic

Release Analytics at the group level

Release Analytics at the group level

SaaS

Self-Managed

In GitLab 13.9, you can view group-level release analytics. This provides you with an aggregated view of all release metrics for each of the projects associated to that group. You can view how many releases belong to this group and what percent of the projects are associated with releases. This feature also serves as a first iteration towards supporting DORA 4 metrics at the group level.

Documentation Issue

JavaScript and Python support for coverage-guided fuzz testing

JavaScript and Python support for coverage-guided fuzz testing

SaaS

Self-Managed

You can now run coverage-guided fuzz tests against your Python and JavaScript apps! These are two of the most popular languages and we’re excited to support them for use in coverage-guided fuzz testing.

To run fuzz tests against apps written in these languages, use the same workflow you would for any other supported language. Create a fuzz testing job to run in your pipeline. When GitLab runs it, any fuzzing results automatically appear in the Security Dashboard, and in the Security tab of the pipeline.

Documentation Issue

JavaScript and Python support for coverage-guided fuzz testing

Override Gitaly Cluster replication factor for specific repositories

Override Gitaly Cluster replication factor for specific repositories

SaaS

Self-Managed

Previously, the replication factor of a Gitaly Cluster was the number of nodes in the cluster. This made it impossible to enable Gitaly Cluster for GitLab instances with very large storage requirements. For example, a 500 TB cluster with 50 nodes would require 25 PB of storage space to be provisioned. To enable Gitaly Cluster to be used for instances with large storage requirements, a way was needed to specify a replication factor less than the total number of nodes in the cluster.

In GitLab 13.9, the replication factor for each repository can be set individually to any number less than the number of nodes in the cluster. This allows for replication of only the most important or active repositories, leaving other less critical repositories on a smaller number of nodes. This will allow organizations to tune their clusters to their own storage and budget constraints. We have also enabled a method to configure a default replication factor for all newly created repositories. This should provide users the necessary means to horizontally scale their Gitaly Cluster.

Documentation Issue

Override Gitaly Cluster replication factor for specific repositories

Easily see repeat failed tests in Unit Test Reports

Easily see repeat failed tests in Unit Test Reports

SaaS

Self-Managed

When you are reviewing failed tests in a pipeline, it’s difficult to tell if a failing test is a legitimate failure that needs investigation or a flaky test that will pass on the next execution.

The next iteration of the repeat failed test counter adds the repeat failed test counter to the unit test report. Now you can see how often a test has failed on the default branch without needing a merge request associated with the test execution.

Documentation Issue

Easily see repeat failed tests in Unit Test Reports

Select CI/CD configuration from any job and reuse it

Select CI/CD configuration from any job and reuse it

SaaS

Self-Managed

Previously, if you wanted to reuse the same configuration in multiple jobs, you had two options: add YAML anchors, which don’t work across different configuration files, or use extends to reuse an entire section.

In this release, we’ve added a new YAML function called !reference, which lets you target the exact configuration you want to reuse as part of your CI/CD pipeline, even if it’s in another file.

Documentation Issue

Select CI/CD configuration from any job and reuse it

View an expanded version of the CI/CD configuration

View an expanded version of the CI/CD configuration

SaaS

Self-Managed

When configuring pipelines, you use keywords like include and extends often. These keywords help break down one long pipeline configuration file into multiple files, which increases readability and reduces duplication. Unfortunately, those keywords can make a pipeline configuration hard to follow. In some configurations, a pipeline configuration file can be mostly composed of a list of other included configuration files.

In this release, you can view a version of your pipeline configuration with all of the include and extends configurations merged together. It’s now much easier to understand more complex pipeline flows and simplifies the debugging process.

Documentation Issue

Resource Group for multi-project and parent-child pipelines

Resource Group for multi-project and parent-child pipelines

SaaS

Self-Managed

You can now benefit from using resource groups if your deployment process uses child pipelines or multi-project pipelines. Such pipelines may contain multiple stages, multiple jobs, and even span across multiple projects. Resource groups ensure only one downstream deployment pipeline runs at a time so you can deploy safely. Previously, resource_group only supported deployment jobs in the same project.

Documentation Issue

Resource Group for multi-project and parent-child pipelines

Follow user activity

Follow user activity

SaaS

Self-Managed

GitLab users can now follow other users’ activity in GitLab! Following users helps you to stay updated on activity by team mates and key project contributors. You can follow or unfollow other users from their user profiles. To see their activity go to the top-level Activity view, and select the Followed Users tab.

Thanks to the amazing work from GitLab contributor Roger Meier from Siemens over the past 3 months, this feature is now available in 13.9.

Documentation Issue

Create Jira issues from Vulnerabilities

Create Jira issues from Vulnerabilities

SaaS

Self-Managed

Many customers use Jira as their single source of truth for tracking issues and engineering work. When using GitLab for SCM and CI/CD, they can take advantage of our existing integration to pass information from MRs and commits into existing Jira issues. However, until now there has been no way to automatically pass information about vulnerabilities detected by security scanners into Jira. This leaves users who rely on Jira to track work no choice but to manually copy vulnerability information into new Jira issues.

To address this, we’re introducing a new ability to create Jira issues directly from a vulnerability’s details. You will see this as a new option in your existing Jira integration settings. Simply enable the new option and select the desired Jira issue type. Available issue types are pulled automatically based on the currently configured Jira target project. Once enabled, all places in your project where you can create GitLab issues from a vulnerability will instead directly create a Jira issue of the configured type.

Documentation Epic

Markdown links for Feature Flags

Markdown links for Feature Flags

SaaS

Self-Managed

This release adds Markdown linking for Feature Flags. Users can mention [feature_flag:<IID>] in discussions or comments to refer a specific Feature Flag. Click on the generated link to go to that Feature Flag’s edit page. This makes collaboration on Feature Flags much easier and more convenient.

Documentation Issue

Allow Deploy Keys to push to protected branches

Allow Deploy Keys to push to protected branches

SaaS

Self-Managed

Prior to GitLab 12.0, Deploy Keys with write access could push commits to protected branches. Support for this was removed due to security concerns, but many users still requested it, as they were using it to ensure that only users with Deploy Keys could push to their repositories. It also eliminates the need to use a service user or machine user, which ties up a license for any team that wants to allow Deploy Keys to push to protected branches just for this use case. We are excited to announce that we resolved this issue and now Deploy Keys can push to protected branches once more while abiding by security best practices. By moving towards an isolated permission model for Deploy Keys, users can now select Deploy Keys to link to protected branches directly from the settings page on protected branches.

Documentation Issue

Allow Deploy Keys to push to protected branches

Request a follow-up review from a Reviewer

Request a follow-up review from a Reviewer

SaaS

Self-Managed

Merge request authors receive feedback from reviewers. Often, this feedback needs to be re-reviewed to make sure all issues have been appropriately addressed. As the author of the contribution, you need to communicate the need for a follow-up to your reviewer.

For reviewers who have already reviewed a merge request, you can now request a re-review. This request triggers a To-Do item and email notification to alert the user that you need a follow-up review of your contribution.

Documentation Issue

Request a follow-up review from a Reviewer

Improvements to the GitLab.com for Jira Cloud Application

Improvements to the GitLab.com for Jira Cloud Application

SaaS

Self-Managed

You can now sync your Jira Cloud project data with GitLab by using the GitLab.com for Jira Cloud application, available on the Atlassian Marketplace. This plugin displays information about your branches, commits, merge requests, deployments, and feature flags in the Jira Development Panel. Use it to see the current status of work in progress, then quickly navigate back to those pages inside of GitLab.

To make these features easier to use, we’ve made significant improvements to the initial setup process over the last few milestones, and now getting your GitLab namespaces connected is easier than ever. To get started, check it out on the Atlassian Marketplace.

Documentation Epic

Improvements to the GitLab.com for Jira Cloud Application

13.9 Other improvements in GitLab 13.9

Email notifications when PAT / SSH Keys are revoked

Email notifications when PAT / SSH Keys are revoked

SaaS

Self-Managed

Managing your namespace includes ensuring you know who has access and how. To promote the security of Personal Access Tokens (PATs), you should be able to revoke a user’s PAT when appropriate. To support this control, we’ve added a revoke button for self-managed administrators to revoke these credentials as needed. Now you can manage your users’ PATs and SSH keys from the Credential Inventory in a single screen.

Your users will now also receive an email notification when their PAT(s) or SSH key(s) are revoked or deleted by an administrator. These improvements provide more control for you to manage your users’ credentials and also provides transparency to the user so they can take actions to replace their credentials with minimal disruption.

Email notifications when PAT / SSH Keys are revoked

Documentation Issue

Improve SAML Timeout Experience

Improve SAML Timeout Experience

SaaS

Self-Managed

When a user’s SAML session for a GitLab.com group reaches the 7 day timeout limit, the user will no longer need to click a confirmation page to renew their session. GitLab will automatically reach out to the Group’s Identity Provider to check for a valid session and extend it as needed. This change improves the group member’s experience and opens the door for decreasing the SAML session timeout in the future.

Documentation Issue

Manage Project Access Tokens through the API

Manage Project Access Tokens through the API

SaaS

Self-Managed

In GitLab 13.9, we introduced an API to manage project access tokens. API Access for project access tokens enable integration for users that want to control project access tokens provisioning in external systems or through custom automation.

SaaS

Self-Managed

In 13.8 we added a User Busy indicator to indicate whether coworkers are available for code reviews and other tasks. In this release, we’ve now included the User Busy indicator in the Assignee section of issue and merge request sidebars.

User Busy status in issue and MR sidebar

Documentation Issue

Filter roadmaps by confidentiality

Filter roadmaps by confidentiality

SaaS

Self-Managed

When viewing a roadmap, there used to be no way to hide confidential epics from the main view. This could be frustrating if you wanted to share your roadmap with a public audience.

In this release we’ve updated the search bar filter to include confidentiality. You now have another layer in which you can refine your roadmap.

Documentation Issue

Show epic comments on user activity feeds

Show epic comments on user activity feeds

SaaS

Self-Managed

Until now, interacting with epics didn’t add a note to the user’s activity page. This could have caused user to think they weren’t creating, managing or interacting with an epic properly, or may simply have made it more difficult for them to find their recent activity.

As of this release, you’ll be able to view all of your epic activity on the user activity page and in user profiles and use it to track your collaboration on epics.

Show epic comments on user activity feeds

Documentation Issue

Autocomplete GitLab CI Variables in VS Code

Autocomplete GitLab CI Variables in VS Code

SaaS

Self-Managed

GitLab CI is fast and highly configurable, but it can be hard to remember all the predefined environment variables, and the wrong typo can make your .gitlab-ci.yml file invalid. To make it easier to configure your GitLab CI pipeline, the 3.11.0 Release of GitLab Workflow provides auto completion for predefined environment variables when editing your .gitlab-ci.yml file.

Tooltips in the auto complete dialog provide information on what the variable can be used for as well as information on supported GitLab and Runner versions. These additional pieces of information really help to ensure your CI configuration will be valid.

Thanks to @KevSlashNull for the contribution!

Autocomplete GitLab CI Variables in VS Code

Documentation Issue

Mark changes as viewed in merge requests

Mark changes as viewed in merge requests

SaaS

Self-Managed

When reviewing a merge request that changes many files, it is challenging to keep track of which files you have already reviewed. Reviews are inefficient when you’re required to re-review or spend additional time regaining context on each file in the merge request.

Files can now be marked as Viewed in merge requests to help signal to yourself that the file has been reviewed. This change allows reviewers to quickly stay up to speed on what they’ve reviewed and what still needs to be reviewed for the merge request.

Mark changes as viewed in merge requests

Documentation Issue

View code review comments in VS Code

View code review comments in VS Code

SaaS

Self-Managed

In a previous release of GitLab Workflow for VS Code it became possible for you to view merge request changes in VS Code. However, seeing the changes proposed by a merge request is only part of reviewing that change and being able to respond to feedback.

With GitLab Workflow 3.10.0, comments provided on changes are now available as part of the diff view. This greatly improves your ability to action feedback provided on your merge request directly in the editor without the additional context switch between VS Code and GitLab.

We’re continuing to expand on Code Review experiences in VS Code. Responding to comments is up next.

Documentation Issue

GPU and smart scheduling support for GitLab Runner

GPU and smart scheduling support for GitLab Runner

SaaS

Self-Managed

Specialized compute workloads like those used in machine learning can significantly benefit from access to GPUs. Developers can configure GitLab Runner to leverage GPUs in the Docker executor by forwarding the --gpu flag. You can also use this with recent support in GitLab’s fork of Docker Machine, which allows you to accelerate workloads with attached GPUs. Doing so can help control costs associated with potentially expensive machine configurations.

Documentation Issue

Group code coverage data graph

Group code coverage data graph

SaaS

Self-Managed

Previously released, group code coverage data is an easy way to see current test coverage of the projects in a group and to get raw data for visualization outside of GitLab. Group code coverage data now includes a graph of the average coverage for all of a group’s projects so you can see how test coverage for the group is trending over time at a glance.

Documentation Issue

Instance configuration to control latest artifacts storage

Instance configuration to control latest artifacts storage

SaaS

Self-Managed

In the last release, we wanted to improve storage consumption management by adding a project setting to disable keeping the latest artifacts. GitLab recognizes that as a self-managed user, you may want to opt-out for your entire instance, so we have added a one-click option for you to disable keeping the latest artifacts for all your projects.

Instance configuration to control latest artifacts storage

Documentation Issue

Automatically authenticate when using the Dependency Proxy

Automatically authenticate when using the Dependency Proxy

SaaS

Self-Managed

By proxying and caching container images from Docker Hub, the Dependency Proxy helps you to improve the performance of your pipelines. Even though the proxy is intended to be heavily used with CI/CD, to use the feature, you had to add your credentials to the DOCKER_AUTH_CONFIG CI/CD variable or manually run docker login in your pipeline. These solutions worked fine, but when you consider how many .gitlab-ci.yml files that you need to update, it would be better if the GitLab Runner could automatically authenticate for you.

Since the Runner is already able to automatically authenticate with the integrated GitLab Container Registry, we were able to leverage that functionality to help you automatically authenticate with the Dependency Proxy.

Now it’s easier to use the Dependency Proxy to proxy and cache your container images from Docker Hub and start having faster, more reliable builds.

Documentation Issue

Dedicated URL for CI/CD dashboard tabs

Dedicated URL for CI/CD dashboard tabs

SaaS

Self-Managed

In 13.8, we added support for deployment frequency charts under CI/CD Analytics. In this milestone, we added the ability to navigate directly to each of the CI/CD analytics charts by introducing a URL for each tab, making it easy to bookmark this page or send it to additional colleagues to view.

Documentation Issue

Support PRIVATE-TOKEN to create releases using the Release-CLI

Support PRIVATE-TOKEN to create releases using the Release-CLI

SaaS

Self-Managed

In this milestone, we added the ability to use the release-cli with a PRIVATE-TOKEN as defined in the Create a release API documentation. This enables overriding the user that creates a release, and supports automation by allowing connection of a project-level PRIVATE-TOKEN or by using a bot user account’s PRIVATE-TOKEN.

Documentation Issue

Assign incidents to milestones

Assign incidents to milestones

SaaS

Self-Managed

Not all incidents have the same severity. Many incidents must be immediately addressed to restore the services customers depend on. But some incidents are less critical and can be prioritized against other work and scheduled for a specific release or milestone for implementation. You can now assign low-severity incidents to a milestone from the right sidebar to manage them from your issue boards.

Documentation Issue

GitLab chart improvements

GitLab chart improvements

SaaS

Self-Managed

Access Control for GitLab Pages is now available for Kubernetes deployments.
It is now possible to set labels on all objects, such as deployments and horizontal pod autoscalers, in a more configurable manner. A new common.labels setting is available for each subchart.
It is now possible to enable proxy protocol support, to support SSH in environments with an upstream proxy that adds the proxy protocol header, such as AWS ELB’s.
redis has been updated to 6.0.10, and gitlab-exporter to v10

Documentation

GitLab Exporter uses significantly less memory

GitLab Exporter uses significantly less memory

SaaS

Self-Managed

GitLab exporter measures various metrics from Redis and the database. We’ve reduced the memory consumption of GitLab exporter by ~60% (~67-71MB) by optimizing its configuration.

This is especially important when running GitLab exporter in memory-constrained environments.

Documentation Issue Epic

Sort global search results by last updated time

Sort global search results by last updated time

SaaS

Self-Managed

You can choose to sort search results on the GitLab search result page. In GitLab 13.9, we added the ability to sort issues and merge requests results by their last updated time.

Documentation Issue

Dependency Scanning now supports npm lock files v2

Dependency Scanning now supports npm lock files v2

SaaS

Self-Managed

Users with node projects using npm 7’s lock file version 2 are now supported. Previously, Dependency Scanning would output the following error:[FATA] [Gemnasium] [2020-10-29T19:02:20Z] ▶ Wrong file format version.

Documentation Issue

Expanded support for Ruby in SAST scans

Expanded support for Ruby in SAST scans

SaaS

Self-Managed

We want to help developers write better code and worry less about common security mistakes. Static Application Security Testing (SAST) helps prevent security vulnerabilities by allowing developers to easily identify common security issues as code is being contributed and mitigate proactively. We’ve updated our Ruby on Rails SAST analyzer (Brakeman) to a new version (v5) which adds support for most Ruby files, not just Rails projects. This change expands the types of Ruby projects we support and introduces new detection rules. If you have a custom SAST.gitlab-ci.yml file, or override the GitLab SAST brakeman job, you may need to update your CI file to enable this additional scanning.

Documentation Issue

License Scanning now starts within its stage

License Scanning now starts within its stage

SaaS

Self-Managed

Previously, the default behavior was to start License Scanning when the pipeline started. This behavior was unexpected and inconsistent with other GitLab Secure jobs. The default behavior has now been changed so that License Scanning starts when the stage it’s in starts, not when the pipeline starts. If you have customized your .gitlab-ci.yml file and want your License Scanning job to only start when its stage starts, remove the needs: [] statement. If you use the default template and wish to revert the behavior, add the needs: [] statement.

Documentation Issue

Performance improvements

Performance improvements

In every release, we continue to make great strides improving GitLab’s performance. We’re committed to making every GitLab instance faster. This includes GitLab.com, an instance with over 1 million registered users!

In GitLab 13.9, we’re shipping performance improvements for issues, projects, milestones, and much more! Some improvements in GitLab 13.9 are:

Security Configuration page for all users

Security Configuration page for all users

SaaS

Self-Managed

With SAST and Secret Detection available to all GitLab customers, we wanted to improve the experience for developers enabling available security scans. We have had a guided configuration experience for Ultimate users and have now made a simplified version of this experience available to all users. This new configuration experience makes it easier for developers to understand which security scans are available to them, find relevant documentation, and provide simple enablement tools. With this initial release, we support a button to create a merge request for SAST. In a future release, we will add additional buttons to easily enable other scan types.

Security Configuration page for all users

Documentation Epic

Group webhooks for subgroups

Group webhooks for subgroups

SaaS

Self-Managed

GitLab has made it easier for you to build subgroup management automation with a subgroup webhook. This webhook is triggered when a subgroup is created or deleted. Automation can now be built without relying on continuous API calls, which is cumbersome and puts an unnecessary performance load on your GitLab instance.

Documentation Issue

Improved user experience for the projects member list

Improved user experience for the projects member list

SaaS

Self-Managed

Our project members list has been redesigned to help project administrators quickly identify key attributes about their members for more effective user management. It includes more descriptive terminology, a new layout, headers for all columns, tooltips for key data elements, and more!

Improved user experience for the projects member list

Documentation Issue

New merge request metric: mean time to merge

New merge request metric: mean time to merge

SaaS

Self-Managed

A new metric, mean time to merge (MTTM), is available in project-level merge request analytics. MTTM is the average time from when a merge request (MR) is created, until the time it is merged. By selecting different dates in the date range selector, you can see how your time to merge MRs changes over time and understand whether you are becoming more efficient at reviewing and merging code.

New merge request metric: mean time to merge

Documentation Issue

Bulk edit iterations on issues in groups and projects

Bulk edit iterations on issues in groups and projects

SaaS

Self-Managed

Instead of having to manually update the iteration on issues one at a time, you can now bulk update iterations from the issue list of a group or project.

Documentation Issue

Filter roadmaps by milestones

Filter roadmaps by milestones

SaaS

Self-Managed

Communicating your strategic plans or reporting on current work in flight requires being able to focus and filter the view of your roadmap. Further refine your roadmap view by filtering the visible epics by milestone.

This feature was behind a feature flag since GitLab 13.7, and now it’s available for everyone.

Documentation Issue

Apply a suggestion with a custom commit message

Apply a suggestion with a custom commit message

SaaS

Self-Managed

Suggesting changes to a merge request makes code review faster and easier by quickly proposing changes and applying the given feedback at a click of a button. However, we had a default commit message for applied suggestions that couldn’t be customized, preventing users from describing the change and eventually violating the project’s commit messages guidelines.

As a result, merge request authors were often forced to squash commits for the whole merge request, or having to manually apply suggestions locally, or going back and rewording the commits after applying the suggestions.

When applying a suggestion you’re now able to write a custom commit message. This allows authors and contributors to accept suggestions and follow commit message best practices for their projects. If no custom commit message is specified the suggestion is committed with a default commit message.

Apply a suggestion with a custom commit message

Documentation Issue

Create changelogs using the GitLab API

Create changelogs using the GitLab API

SaaS

Self-Managed

Previously, generating a changelog using GitLab was a manual process. Release Managers had to collect all the changes for a given release and then manually add them to a changelog file, which was time-consuming and prone to error. To make this process easier, we have now added an API that will automatically generate a changelog for a given release based on commit history. This enables development teams to better communicate changes to end users by delivering a consistent and comprehensive set of changelogs for every release.

Documentation Issue

Merge Refs for changes in merge requests

Merge Refs for changes in merge requests

SaaS

Self-Managed

Merge request diffs have been calculated by git diff target...source which compares HEAD of the target with the merge base of target and source. This works well, until changes from the target branch are merged into the source branch, creating a complete mess of the diff.

Merge requests now compare to <default branch> (HEAD) by default when viewing the changes tab of a merge request. This provides a more accurate and up-to-date diff of the changes during your review.

Documentation Epic

Access webhook pipeline trigger payloads in CI/CD jobs

Access webhook pipeline trigger payloads in CI/CD jobs

SaaS

Self-Managed

When triggering a pipeline with a webhook, the webhook’s payload was not accessible from any jobs in the resulting pipeline. In some cases, the payload carries important information that can determine how the triggered pipeline should work. In this release, we’ve added a new predefined variable to capture the webhook payload so you can easily incorporate it within your triggered pipelines.

Documentation Issue

GitLab Runner 13.9

GitLab Runner 13.9

SaaS

Self-Managed

We’re also releasing GitLab Runner 13.9 today! GitLab Runner is the lightweight, highly-scalable agent that runs your build jobs and sends the results back to a GitLab instance. GitLab Runner works in conjunction with GitLab CI/CD, the open-source continuous integration service included with GitLab.

What’s new:

Bug Fixes:

The list of all changes is in the GitLab Runner CHANGELOG.

Documentation

Install GitLab Runner more easily with in-product help

Install GitLab Runner more easily with in-product help

SaaS

Self-Managed

When you’re not using the shared runners on GitLab.com, getting started with GitLab CI requires installing GitLab Runner and registering the runner to execute jobs in your pipeline. While the GitLab Runner installation process is well-documented, one of our goals is to make it as easy as possible for users to get started with GitLab CI. An initial step on this journey is to release a new GitLab Runner guided install modal window. With this feature, you can select a target platform, copy, and run the install commands without navigating away from the GitLab UI.

Install GitLab Runner more easily with in-product help

Documentation Issue

Allow or prevent duplicate Maven uploads

Allow or prevent duplicate Maven uploads

SaaS

Self-Managed

You can use the GitLab Package Registry to publish your Java dependencies with Maven or Gradle. By default, you can publish the same package name and version multiple times. This default was chosen based on the behavior of the most common public registries.

However, many of you have expressed that you’d like to prevent duplicate uploads, especially when it comes to releases. We’ve added a new group setting for the Package Registry, and you can now choose whether you’d like to allow or prevent duplicate Maven or Gradle uploads. As mentioned, to match the behavior of the public registries, duplicates will be allowed by default.

You can adjust this setting by using the GitLab API or from the application by navigating to Settings > Packages & Registries. In the coming milestones, we plan to expand this setting for each package manager format and add it to the user interface. Please follow along in the epic or consider contributing a change!

Documentation Issue

ConfigMap support for Kubernetes Agent Server

ConfigMap support for Kubernetes Agent Server

SaaS

Self-Managed

Users of Kubernetes Agent Server (kas) until now had to use command line arguments to customize their Agent Server installations. This setup proves inadequate for large-scale installations where declarative, repeatable setups are a core part of the workflow, and many arguments need custom settings. With the current GitLab release, the Kubernetes Agent Server helm charts can be installed by custom configs that get merged with the default configurations to make it simple to integrate an Agent Server installation with existing observability and monitoring tools.

Documentation Issue

Keyboard shortcut to toggle between GitLab and GitLab Next

Keyboard shortcut to toggle between GitLab and GitLab Next

SaaS

Self-Managed

This milestone introduces a keyboard shortcut that toggles between GitLab and GitLab Next. By using the g and x keys, which work from any area of GitLab, you can easily switch between GitLab and GitLab Next. A huge thanks to Yogi for a great community contribution!

Documentation Issue

Vault JWT (JSON Web Token) supports GitLab environments.

Vault JWT (JSON Web Token) supports GitLab environments.

SaaS

Self-Managed

To simplify integrations with HashiCorp Vault, we’ve shipped Vault JWT token support. From the launch, you could restrict access based on data in the JWT. This release gives you a new dimension for restricting access to credentials: the environment a job targets.

This release extends the existing Vault JWT token to support environment-based restrictions too. As the environment name could be supplied by the user running the pipeline, we recommend you use the new environment-based restrictions with the already-existing ref_type values for maximum security.

Documentation Issue

Access Control for Pages is now supported for Kubernetes deployments of GitLab

Access Control for Pages is now supported for Kubernetes deployments of GitLab

SaaS

Self-Managed

In GitLab 13.8 initial support for GitLab Pages was introduced for deployments of GitLab on Kubernetes, allowing users to easily deploy static websites.

With the release of GitLab 13.9, Access Control is now supported, optionally restricting access to the pages site to members of the project. All Pages features are now supported in the GitLab Helm chart.

Documentation Issue

Omnibus improvements

Omnibus improvements

SaaS

Self-Managed

GitLab’s repository installation script now utilizes CentOS 7 packages for Amazon Linux 2 systems. Existing deployments of GitLab on Amazon Linux 2 can re-run the installation script to update. Note Amazon Linux 2 is not currently officially supported.
redis has been updated to 6.0.10, logrotate to 3.18.0, and libtiff to 4.2.0
GitLab 13.9 includes Mattermost 5.31.1, an open source Slack-alternative whose newest Extended Support Release offers bug fixes for increased stability and improvements in plugins. This version also includes security updates and upgrade from earlier versions is recommended.

Documentation

Reduced Puma memory consumption on small instances

Reduced Puma memory consumption on small instances

SaaS

Self-Managed

By default Puma, the web server used by GitLab, uses multiple workers to improve performance. This is important for scaling GitLab but also results in increased memory consumption.

Small instances with few users and limited resources might not require multiple workers. For this use case, GitLab now supports running Puma in single mode, which reduces the memory consumption of the application at rest by around 250 MB.

Check out the list of current limitations. when running Puma in single mode.

Documentation Epic

Bug fixes

Bug fixes

Some of the notable bug fixes in GitLab 13.9 are:

Opening Admin Settings page results in the 500 error
Unit test report not populating when filename attribute is not present
Builds with a dot “.” in their name fails to load test details in the UI
SAST flawfinder fails in sast CI job with UnicodeDecodeError error
SAST security-code-scan panics: index out of range error
Housekeeping is not run on wiki repos, causing performance degradation over time
Create issue from Vulnerability details - Edited text is discarded
Description of Vulnerability is empty in GraphQL
Network policy preview for deny all shows as allow all
Error “Filenames contained invalid characters” when attaching images to ticket
not_adjacent error when moving designs around
Bug with roadmaps where epics show up twice in the UI
When adding sub epic from sub group, wrong epic is added
Geo: Fix concurrent VerificationBatchWorker jobs
gitlab-ctl promotion-preflight-checks incorrectly fails with 0%
UpdatePagesService jobs may cause backup jobs to fail with error ‘directory has vanished’
Dependency Scanning analyzer was not updating the Vulnerability Database each scan for specific customers. Please read our blog for more details. Impacted customers are:
- Customers with an edited Dependency Scanning template that pins their analyzers to a non-major-only tag (for example gemnasium:2.27.0)
- Customers running in an Offline Environment
- Customers that have a mirror of the analyzer docker registry
- self-managed customers with a pull policy of never or if-not-present.
Resource events created via the issue update API does not follow the updated_at param
Project labels API return “404 Label Not Found” if label name contains dot “.”
Project name to path conversion in API mangles dots
Iteration reports not scoping correctly
“List pipeline jobs” GitLab API does not return an information about retired jobs anymore
Delayed and manual jobs with DAG are not skipped even they need a failed job

Bug Fixes

Dependency Scanning support added for sbt 1.3.0

Dependency Scanning support added for sbt 1.3.0

SaaS

Self-Managed

Users with Scala projects using sbt 1.3 and later can now benefit from Dependency Scanning. Previously only sbt versions 1.2 and below were supported.

Documentation Issue

Improved Android SAST Support

Improved Android SAST Support

SaaS

Self-Managed

Since GitLab 13.5, we’ve supported mobile SAST via MobSF. We’ve updated this analyzer to version 2.5 which includes many improvements to mobile scanning capabilities for Android. Major improvements include: adding OWASP MSTG mappings for improved vulnerability information, support for Android 10 API 29, xapk support, and National Information Assurance Partnership (NIAP) analysis for Android.

Our Mobile SAST security scanner is still considered experimental and requires enabling experimental features via a CI variable, SAST_EXPERIMENTAL_FEATURES. We expect to remove this requirement in an upcoming GitLab release.

Documentation Issue

Multi-project support for .NET SAST scanning

Multi-project support for .NET SAST scanning

SaaS

Self-Managed

GitLab security scans automatically detect code language and run appropriate analyzers. With monorepos, microservices, and multi-project repositories, more than one project can exist within a single GitLab repository. Previously our .NET SAST tool could only detect single projects in repositories. With this release, our .NET SAST analyzer can now intelligently detect multiple solution files (.sln) in .NET projects and report vulnerabilities across them. This will make it easier and more streamlined for users with multi-project .NET repos to leverage our SAST scanning.

Documentation Issue

SAST Support for .NET 5

SAST Support for .NET 5

SaaS

Self-Managed

Microsoft’s release of .NET 5.0 is the next major release of .NET Core which supports more types of apps and more platforms than .NET Core or .NET Framework. We have updated our .NET SAST analyzer, Security Code Scan to support this new version which is also now supported with our SAST language detection allowing GitLab SAST to automatically detect .NET 5 projects. This change was part of a community contribution by @shaun.burns.

Documentation Issue

Vulnerability Report Activity filter

Vulnerability Report Activity filter

SaaS

Self-Managed

Vulnerability Reports are often the primary way security teams triage and manage vulnerabilities. The current filtering and sorting options provide quick ways to focus the list view on a subset of vulnerabilities for more efficient workflows. You can also see any vulnerabilities that have associated issues or which subsequent scans indicate are resolved. This Activity column indicates at a glance which vulnerabilities might be ready to close out, which are in progress, and which ones might need some attention. However, this column was not one you could filter or sort on!

Now have even more control of your Vulnerability Report experience with the introduction of an Activity filter. Available in the Project, Group, and Security Center Vulnerability Reports, this new filter allows you to view vulnerabilities with issues that are not yet resolved, that are resolved but have no associated issues, that have issues and are resolved, or that have no activity. The available filter options are mutually exclusive sets, allowing you to drill into precisely the vulnerability list view you need for any task.

Documentation Issue

Deprecations Deprecations

Container Scanning Engine Clair

Container Scanning Engine Clair

GitLab 14.0 will replace its container scanning engine with Trivy. Currently, GitLab uses the open source Clair engine for container scanning. GitLab 13.9 deprecates Clair. For any 13.x release, customers can continue to use Clair without making any changes to their CI files; however, note that GitLab will no longer update or maintain that scanning engine. Beginning in the 14.0 release, Trivy will become the new default scanner and will receive regular updates and the latest features. Customers are advised to review their CI files in advance of the 14.0 release and to follow these instructions to ensure that their container scanning jobs continue to work. Customers can provide feedback and get additional details on our open deprecation issue.

Planned removal date: June 22, 2021

Deprecate Container Registry log formatters

Deprecate Container Registry log formatters

Currently, GitLab supports:

Text, JSON, and logstash log formatting for app logs.
Text, JSON, and combined log formatting for access logs.

We will deprecate both logstash and combined, unifying the formatters for both app and access logs with only two options text (for development) and JSON.

Planned removal date: February 22, 2021

Deprecate Container Registry logging hooks

Deprecate Container Registry logging hooks

The Container Registry currently supports logging hooks that can only be used for email notifications.

These days, alerts based on log entries are commonly handled by separate tools. As far as we know, none of our users rely on this functionality and it is not used at GitLab either. The implementation of this feature is tightly coupled with the underlying logging library, which is a limitation for our ability to switch dependencies without affecting the available features.

In an effort to simplify the registry features and configurations, we will drop support for logging hooks.

Planned removal date: February 22, 2021

Deprecate Container Registry maxidle and maxactive Redis pool settings

Deprecate Container Registry maxidle and maxactive Redis pool settings

Some of the configuration settings that we currently expose for the Redis connection pool are tied to the underlying Redis client and do not have an equivalent in alternative libraries. As we start working on improving the Redis integration, such as adding support for Sentinel, we decided to start working towards replacing the current Redis client dependency with a more feature-rich alternative that can be better supported. To do this, we need to replace the current Redis pool configuration settings that are tied to the current client library.

We intend to:

Remove the redis.pool.maxidle and redis.pool.maxactive settings.
Add redis.pool.size (maximum number of connections), redis.pool.minidle (minimum number of idle connections), and redis.pool.maxlifetime (maximum amount of time a connection may be reused) settings.

Planned removal date: February 22, 2021

Deprecate Container Registry support for Bugsnag

Deprecate Container Registry support for Bugsnag

Bugsnag is one of the error reporting services supported by the Container Registry. As far as we know, none of our users rely on this service, and at GitLab we use Sentry. In an effort to simplify and consolidate the supported error reporting services, we intend to add support for Sentry and remove support for Bugsnag.

Planned removal date: February 22, 2021

Deprecate Container Registry support for NewRelic

Deprecate Container Registry support for NewRelic

NewRelic is one of the error reporting services supported by the Container Registry. As far as we know, none of our users rely on this service, and at GitLab we use Sentry. In an effort to simplify and consolidate the supported error reporting services, we intend to add support for Sentry and remove support for NewRelic.

Planned removal date: February 22, 2021

Deprecate Container Registry support for TLS 1.0 and 1.1

Deprecate Container Registry support for TLS 1.0 and 1.1

Support for TLS 1.0 and TLS 1.1 has been deprecated and removed for GitLab for security reasons. We will do the same for the GitLab Container Registry, which currently supports 1.0 (default), 1.1, 1.2, and 1.3. and defaults to 1.0.

We will deprecate support for TLS 1.0 and TLS 1.1, showing a warning log message when these are used. Support for these versions will be removed and TLS 1.2 will become the default.

Planned removal date: February 22, 2021

Deprecate and remove secret_detection_default_branch job

Deprecate and remove secret_detection_default_branch job

To ensure Secret Detection was scanning both default branches and feature branches we introduced two separate secret detection CI jobs in our managed Secret-Detection.gitlab-ci.yml template. These two CI jobs, secret_detection_default_branch and secret_detection, created confusion and complexity in the CI rules logic. As part of this deprecation, we are moving the rule logic into script which will determine how the secret_detection job is run (historic, on a branch, commits, etc). If you override or maintain custom versions of SAST.gitlab-ci.yml, Secret-Detection.gitlab-ci.yml, you must update your CI templates. We strongly encourage inheriting and overriding our managed CI templates to future proof your CI templates. We will stop supporting the old secret_detection_default_branch job with GitLab 14.0, releasing June 22, 2021.

Planned removal date: March 17, 2021

Deprecate disk source configuration for GitLab Pages

Deprecate disk source configuration for GitLab Pages

GitLab Pages API-based configuration has been available since GitLab 13.0 and will replace the disk source configuration, which will be removed in GitLab 14.0. We recommend that you move away from using disk source configuration and move to gitlab for an API-based configuration, since disk will no longer be supported and cannot be chosen. You can migrate away from the ‘disk’ source configuration by setting gitlab_pages['domain_config_source'] = "gitlab" in your gitlab.rb/etc/gitlab/gitlab.rb file. We recommend that you do this before GitLab 14.0 so you can find and troubleshoot any potential problems ahead of time.

Planned removal date: June 22, 2021

Deprecate pulls that use v1 of the Docker registry API

Deprecate pulls that use v1 of the Docker registry API

GitLab disabled pulls via the Docker registry v1 APIs on January 22, 2021. Deprecated by Docker in June, 2019, deprecating this feature allows the GitLab team to focus on features and fixes that provide you with more value and target current registry use cases.

Existing users of the v1 registry API on GitLab can move to the v2 registry API by completing the following steps:

Update your Docker Engine to 17.12 or later so it is compatible with the v2 registry API.
If you have content in GitLab that is in the v1 format, you can move it to the v2 format by using a newer Docker client (more recent than 1.12) to rebuild the image and push it to GitLab.

Planned removal date: February 22, 2021

Deprecating SAST analyzer SAST_GOSEC_CONFIG variable in favor of custom rulesets

Deprecating SAST analyzer SAST_GOSEC_CONFIG variable in favor of custom rulesets

With the release of SAST Custom Rulesets in GitLab 13.5 we allow greater flexibility in configuration options for our Go analyzer (GoSec). As a result we no longer plan to support our less flexible SAST_GOSEC_CONFIG analyzer setting. This variable will be deprecated in GitLab 13.10, and removed in GitLab 14.0. If you override or leverage SAST_GOSEC_CONFIG in your CI file, you will need to update your SAST CI configuration or pin to an older version of the GoSec analyzer . We strongly encourage inheriting and overriding our managed CI templates to future proof your CI templates. We will remove the old SAST_GOSEC_CONFIG variable in GitLab 14.0, releasing June 22, 2021.

Planned removal date: March 22, 2021

Deprecation of release description in the Tags API

Deprecation of release description in the Tags API

GitLab 14.0 will remove support for the release description in the Tags API. You’ll no longer be able to add a release description when creating a new tag. You’ll also no longer be able to create or update a release through the Tags API. Please migrate to use the Releases API instead.

Planned removal date: June 22, 2021

Deprecations for Dependency Scanning

Deprecations for Dependency Scanning

Previously to exclude a DS analyzer, you needed to remove it from the default list of analyzers and use that to set the DS_DEFAULT_ANALYZERS variable in your project’s CI template. We determined it should be easier to avoid running a particular analyzer without losing the benefit of newly added analyzers. As a result we ask you to migrate from DS_DEFAULT_ANALYZERS to DS_EXCLUDED_ANALYZERS when it is available. Read about it in issue #287691 or this blog post.

Previously to prevent the Gemnasium analyzers to fetch the advisory database at runtime, you needed to set the GEMNASIUM_DB_UPDATE env variable. Though, this is not documented properly and its naming is inconsistent with the equivalent BUNDLER_AUDIT_UPDATE_DISABLED variable. As a result we ask you to migrate from GEMNASIUM_DB_UPDATE to GEMNASIUM_UPDATE_DISABLED when it is available. Read about it in issue #215483 or this blog post.

Planned removal date: June 22nd, 2021

Fuzz test jobs will fail with allow_failure if vulnerabilities are found

Fuzz test jobs will fail with allow_failure if vulnerabilities are found

To make sure our fuzz testing jobs behave consistently with each other, as part of 14.0, all fuzz testing jobs will start failing if a job finds vulnerabilities. These jobs will have allow_failure=true set in them so you will get a warning but your pipeline as a whole will not fail if a vulnerability is found.

This is the current behavior for several of the fuzz scanners, such as the Go and C++ fuzz engines.

No action is required on your part to use this new behavior. If you are checking the results of a pipeline fuzz testing job as part of a script, consider if those scripts will need any updates.

Planned removal date: June 22, 2021

Git default branch name change

Git default branch name change

Every Git repository has an initial branch. It’s the first branch to be created automatically when you create a new repository. By default, this initial branch is named master. Future Git versions will change the default branch name in Git from master to main. In coordination with the Git project and the broader community, GitLab will be changing the default branch name for new projects on both our SaaS (GitLab.com) and self-managed offerings starting with GitLab 14.0. This will not affect existing projects.

GitLab has already introduced changes that allow users to change the default branch name both at the instance-level (for self-managed users) and at the group-level (for both SaaS and self-managed users). We encourage users to make use of these features to set default branch names on new projects.

For more information, see the related epic and related blog post.

Planned removal date: June 22, 2021

GitLab OAuth implicit grant deprecation

GitLab OAuth implicit grant deprecation

As OAuth 2.1 omits the implicit grant, GitLab will deprecate the OAuth 2 implicit grant flow. Beginning in 14.0, new applications will not be able to be created with the OAuth 2 implicit grant flow. Existing OAuth implicit grant flows will no longer be supported in 14.4. Please migrate existing applications to other supported OAuth2 flows before release 14.4.

Planned removal date: June 22, 2021

GitLab Runner installation to ignore the skel directory

GitLab Runner installation to ignore the skel directory

In GitLab Runner 14.0, the installation process will ignore the skel directory by default when creating the user home directory. Refer to issue #4845 for details.

Planned removal date: Jun 22, 2021

Helm v2 support

Helm v2 support

Helm v2 was officially deprecated in November of 2020, with the stable repository being de-listed from the Helm Hub shortly thereafter. With the release of GitLab 14.0, which will include the 5.0 release of the GitLab Helm chart, Helm v2 will no longer be supported.

The Cloud Native GitLab Helm chart will not immediately be altered to Helm v3’s new schema, but moving forward there are opportunities for improved maintainability we would like to be able to leverage. Deprecating the constraint that functionality be limited to that within Helm v2 allows us to better the experience for our users.

Planned removal date: June 22, 2021

Legacy Feature Flags Deprecation

Legacy Feature Flags Deprecation

Legacy Feature Flags became read-only in GitLab 13.4. Support for legacy Feature Flags will be removed in GitLab 14.0. You must migrate your legacy Feature Flags to the new version. You can do this by first taking a screenshot of the legacy flag for tracking. Then delete the flag through the API or UI (you don’t need to alter the code) and create a new Feature Flag with the same name as the legacy flag you deleted. Also, make sure the strategies and environments match the deleted flag. We created a video tutorial to help with this migration.

Planned removal date: June 22, 2021

Limit projects returned in GET /groups/:id/

Limit projects returned in GET /groups/:id/

To improve performance, we will be limiting the number of projects returned from the GET /groups/:id/ API call to 100. To get a complete list of projects, please use the GET /groups/:id/projects API call.

Planned removal date: June 22, 2021

Make pwsh the default shell for newly-registered Windows Runners

Make pwsh the default shell for newly-registered Windows Runners

In GitLab Runner 13.2, PowerShell Core support was added to the Shell executor. In 14.0, pwsh will be the default shell for newly-registered Windows runners. Windows CMD will still be available as a shell option for Windows runners. Refer to issue #26419 for details.

Planned removal date: Jun 22, 2021

Migrate from SAST_DEFAULT_ANALYZERS to SAST_EXCLUDED_ANALYZERS

Migrate from SAST_DEFAULT_ANALYZERS to SAST_EXCLUDED_ANALYZERS

Until 13.9, if you wanted to avoid running one particular GitLab SAST analyzer, you needed to remove it from the long string of analyzers in the SAST.gitlab-ci.yml file and use that to set the SAST_DEFAULT_ANALYZERS in your project’s CI file. If you did this, it would exclude you from future new analyzers because this string hard codes the list of analyzers to execute. We avoid this problem by inverting this variable’s logic to exclude, rather than choose default analyzers. Beginning with 13.9, we are migrating to SAST_EXCLUDED_ANALYZERS in our SAST.gitlab-ci.yml file. We encourage anyone who uses a customized SAST configuration in their project CI file to migrate to this new variable. If you have not overridden SAST_DEFAULT_ANALYZERS, no action is needed. SAST_DEFAULT_ANALYZERS will be removed in GitLab 14.0, which will release on June 22, 2021.

Planned removal date: February 22, 2021

Pin Static Analysis analyzers and tools to minor versions

Pin Static Analysis analyzers and tools to minor versions

With the maturity of GitLab Secure scanning tools, we’ve needed to add more granularity into the versioning of our SAST analyzers. This change will make it easier for customers to set specifically which version of analyzers they want to run, introducing more control into how customers choose to upgrade their SAST scanning. Prior to 13.10, GitLab shared a major version number for all our SAST analyzers and tools and prevented the use of semantic version numbering for updates.

Beginning in 13.10 GitLab SAST and Secret Detection will start using major.minor version pinning in our .gitlab-ci.yml files and will ship major.minor tags on analyzer containers. We will also deprecate the SAST_ANALYZER_IMAGE_TAG variable in our managed SAST.gitlab-ci.yml CI template in favor of major.minor tags for each analyzer. If you override or maintain custom versions of SAST.gitlab-ci.yml, Secret-Detection.gitlab-ci.yml or rely on analyzer x-y-stable tags, you will want to update your CI templates. We strongly encourage inheriting and overriding our managed CI templates to future proof your CI templates. This change will allow you to instead override with a pinned major.minor version to gain more granular control of future feature updates. We will remove shared major version pinning and the SAST_ANALYZER_IMAGE_TAG variable in our managed SAST.gitlab-ci.yml with GitLab 14.0, releasing June 22, 2021.

Planned removal date: March 22, 2021

PostgreSQL 11 support

PostgreSQL 11 support

PostgreSQL 12 will be the minimum required version in GitLab 14.0. It offers significant improvements to indexing, partitioning, and general performance benefits.

Starting in GitLab 13.7, all new installations default to version 12. From GitLab 13.8, single-node instances are automatically upgraded as well. If you aren’t ready to upgrade, you can opt-out of automatic upgrades.

Multi-node database instances will need to switch from repmgr to Patroni, prior to upgrading with Patroni. Geo secondaries can then be updated and re-synchronized.

Planned removal date: June 22, 2021

Removals for License Compliance

Removals for License Compliance

In 13.0, we deprecated the License-Management CI template and renamed it License-Scanning. We have been providing backward compatibility by warning users of the old template to switch. Now in 14.0, we are completely removing the License-Management CI template. Read about it in issue #216261 or this blog post.

Planned removal date: June 22nd, 2021

Remove /usr/lib/gitlab-runner symlink from package

Remove /usr/lib/gitlab-runner symlink from package

In GitLab Runner 13.3, a symlink was added from /user/lib/gitlab-runner/gitlab-runner to /usr/bin/gitlab-runner. In 14.0, we will remove this symlink and the runner will be installed in /usr/bin/gitlab-runner. Refer to issue #26651 for details.

Planned removal date: Jun 22, 2021

Remove FF_SHELL_EXECUTOR_USE_LEGACY_PROCESS_KILL feature flag

Remove FF_SHELL_EXECUTOR_USE_LEGACY_PROCESS_KILL feature flag

In GitLab Runner 13.1, issue #3376, we introduced sigterm and then sigkill to a process in the Shell executor. We also introduced a new feature flag, FF_SHELL_EXECUTOR_USE_LEGACY_PROCESS_KILL, so you can use the previous process termination sequence. In GitLab Runner 14.0, issue #6413, we will remove the feature flag.

Planned removal date: Jun 22, 2021

Remove FF_USE_GO_CLOUD_WITH_CACHE_ARCHIVER feature flag

Remove FF_USE_GO_CLOUD_WITH_CACHE_ARCHIVER feature flag

In GitLab Runner 14.0, we will remove the FF_USE_GO_CLOUD_WITH_CACHE_ARCHIVER feature flag. Refer to issue #27175 for details.

Planned removal date: Jun 22, 2021

Remove Ubuntu 19.10 (Eoan Ermine) package

Remove Ubuntu 19.10 (Eoan Ermine) package

Ubuntu 19.10 (Eoan Ermine) reached end of life on Friday, July 17, 2020. In GitLab Runner 14.0, we will remove the Ubuntu 19.10 (Eoan Ermine) from our package distribution. Refer to issue #26036 for details.

Planned removal date: Jun 22, 2021

Remove off peak time mode configuration for Docker Machine autoscaling

Remove off peak time mode configuration for Docker Machine autoscaling

In GitLab Runner 13.0, issue #5069, we introduced new timing options for the GitLab Docker Machine executor. In GitLab Runner 14.0, we plan to remove the old configuration option, off peak time mode.

Planned removal date: Jun 22, 2021

Remove success and failure for finished build metric conversion

Remove success and failure for finished build metric conversion

In GitLab Runner 13.5, we introduced failed and success states for a job. To support Prometheus rules, we chose to convert success/failure to finished for the metric. In 14.0, we will remove the conversion. Refer to issue #26900 for details.

Planned removal date: Jun 22, 2021

Remove support for Windows Server 1903 image

Remove support for Windows Server 1903 image

In 14.0, we will remove support for Windows Server 1903 as Microsoft ended support for this version on 2020-08-12. Refer to issue #27551 for details.

Planned removal date: Jun 22, 2021

Remove translation from step_script to build_script in custom executor

Remove translation from step_script to build_script in custom executor

In GitLab Runner 13.2 a translation for step_script to build_script was added to the custom executor. In 14.0 the ‘build_script’ stage will be replaced with ‘step_script`. Refer to issue #26426 for details.

Planned removal date: Jun 22, 2021

Renewal of the stable Auto Deploy template in Auto DevOps

Renewal of the stable Auto Deploy template in Auto DevOps

In GitLab 14.0, we will renew the Auto Deploy CI template to the latest version. This includes new features, bug fixes, and performance improvements with a dependency on the v2 auto-deploy-image. This latest template is opt-in. Unless you specifically customize Auto DevOps in your project, it uses the stable template with a dependency on the v1 auto-deploy-image.

Since the v1 and v2 versions are not backwards compatible, your project might encounter an unexpected failure if you already have a deployed application. Please follow the upgrade guide to upgrade your environments. You can also start using the latest template today by following the early adoption guide.

Planned removal date: June 22, 2021

Sidekiq Cluster queue selector configuration option has been renamed

Sidekiq Cluster queue selector configuration option has been renamed

GitLab contains a large number of background job queues. Some administrators may want to have multiple background job processes, each running different workloads.

Previously, we only supported specifying the queues handled for a particular process by name, or using an experimental option to allow selecting queues by attributes.

This option - previously experimental_queue_selector - is no longer experimental and has been renamed to queue_selector. experimental_queue_selector will continue to work until GitLab 14.0.

Planned removal date: June 22, 2021

Unicorn will be removed in favor of Puma for GitLab self-managed

Unicorn will be removed in favor of Puma for GitLab self-managed

Unicorn support is deprecated and will be removed in GitLab 14.0. You must migrate to Puma before upgrading to GitLab 14.0.

Planned removal date: June 22, 2021

WIP (work in progress) merge requests term deprecated

WIP (work in progress) merge requests term deprecated

We renamed the WIP (work in progress) term for merge requests to “draft”, because it’s more inclusive and self-explanatory. The WIP term is now deprecated. We will support its use through the next major GitLab release (14.0), after which it will be removed.

Planned removal date: June 22, 2021

Removals and breaking changes Removals and breaking changes

Geo Foreign Data Wrapper settings removal in 14.0

Geo Foreign Data Wrapper settings removal in 14.0

As announced in GitLab 13.3, the following configuration settings in /etc/gitlab/gitlab.rb are deprecated and will be removed in 14.0:

geo_secondary['db_fdw']
geo_postgresql['fdw_external_user']
geo_postgresql['fdw_external_password']
gitlab-_rails['geo_migrated_local_files_clean_up_worker_cron']

Removal date: June 22, 2021

Legacy storage removal in 14.0

Legacy storage removal in 14.0

As announced in GitLab 13.0 legacy storage is deprecated and will be removed in GitLab 14.0.

Before upgrading to GitLab 14.0 you must migrate fully to hashed storage.

Removal date: June 22, 2021

Important notes on upgrading to GitLab Important notes on upgrading to GitLab 13.9

Cohorts is a feature available in the Admin Area of self-managed installations of GitLab. It shows how many new users have been added to GitLab, how many of them become active users, and how many of those users continue to use GitLab month over month since being added. In GitLab 13.9, Cohorts has been moved from the Analytics section to the Overview > Users section so that it is discoverable alongside other user metrics.

Changelog Changelog

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

Installing Installing

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

Updating Updating

Check out our update page.

Questions? Questions?

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

GitLab Subscription Plans GitLab Subscription Plans

Free
Free-forever features for individual users
Premium
Enhance team productivity and coordination
Ultimate
Organization wide security, compliance, and planning

Try all GitLab features - free for 30 days

Cover image licensed under CC0

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.

Share your feedback

Take GitLab for a spin

See what your team could do with The DevSecOps Platform.

Get free trial

Have a question? We're here to help.

Talk to an expert

GitLab 13.9 Release