13.11

GitLab 13.11 Release

GitLab 13.11 released with Kubernetes Agent and Pipeline Compliance

GitLab 13.11 released with Kubernetes Agent, Compliant Pipelines, and features for speedier pipelines - and much more!

On this Earth Day we are thinking about growth. Our customers are scaling their DevOps practices and with growth comes the need for even greater efficiencies and automated controls. The GitLab Agent for Kubernetes is now available on GitLab.com to help you benefit from fast, pull-based deployments to your cluster, while GitLab.com manages the necessary server-side components of the Agent. Compliant Pipeline Configurations let you define enforceable pipelines that will run for any project assigned a corresponding compliance framework, even custom ones. We also have a host of features to improve pipeline efficiency and measurement, to provide On-call Scheduling, and even more security enhancements. These are just a few of the 50+ significant new features and improvements in this release.

Controls to help you grow safely and efficiently

Controls can keep your automation on track as you grow and scale while simplifying compliance efforts. The GitLab Agent for Kubernetes is core to GitLab's Kubernetes integrations and is now available on GitLab.com. The Agent-based integration supports pull-based deployments which are preferred by security and quickly becoming a popular method for Kubernetes deployment practices. The agent also supports Network Security policy integration and alerts which enables fine-tuned RBAC controls within your clusters. Compliant Pipeline Configurations let you enforce a higher degree of separation of duties and reduce your business risks by defining enforceable pipelines that will run for any project assigned a corresponding compliance framework. At the same time, Custom Compliance Framework Labels allow you to use your own requirements beyond the usual ones like PCI, HIPPA and such. The new Admin Mode increases security and control of your GitLab instance by requiring admin users to reverify their credentials before running administrative commands. Audit reports are easier now too with a new export feature in your self-managed GitLab instance to see, all in one place, what groups, subgroups, and projects users have access to.

Speedier pipelines

“Speedy, reliable pipelines” is one of our core product themes, and we’ve delivered on that promise this month with a host of pipeline improvements.

The Pipeline Editor helps you get to work even faster and stay more productive once you begin. The new Empty State enhancement will allow new users to begin working with the pipeline editor on a new, blank pipeline file without having to create a config file first. The ability to configure multiple cache keys in a single job will help you increase your pipeline performance and you can measure these improvements from the CI/CD dashboard, where a new DORA 4 graph will show lead time for changes via time for code to be committed and deployed to production. As a related note, metrics on DevOps Adoption are now available at the group level allowing users to understand how GitLab's DevOps capabilities are being adopted.

Securing your software supply chain

Security pros will be happy to see the addition of the Semgrep flexible rule syntax to extend and modify custom detection rules, a popular request from GitLab SAST customers. We've also added support for custom certificates and email alerts for key expirations. You can now improve your security posture by enforcing SAML for Git activity. The new On-call Schedule Management routes alerts received in GitLab to the on-call engineer in the schedule for that project. This will be particularly helpful as we mature our security alerts in the future, providing a valuable incident management capability with end-to-end visibility across the entire DevOps process.

Read on for more features, performance enhancements and changes! To preview what's coming in next month’s release, check out our Upcoming Releases page and our 13.12 release kickoff video.

Join us for an upcoming event

GitLab MVP badge

MVP This month's Most Valuable Person (MVP) is awarded to Yogi

In the last month, Yogi has made multiple contributions to the GitLab Status Page which have improved performance, polished the UI, and brought us closer to our ultimate vision. Yogi added the banner systems notice which helps users understand from a glance if there is an incident or if all systems are operational. He optimized the mobile view to be more responsive so that on-call responders have a better experience on their devices. He also moved Incidents and Incident comments to vue.js components which helps us create a consistent and lovable user experience across the product.

This is not Yogi’s first time being selected as GitLab’s MVP - he was also recognized in 13.8 for his 30+ merge requests that fixed long-standing bugs, improved our UX, and helped with our platform consistency. Thank you, Yogi!

13.11 Key improvements released in GitLab 13.11

GitLab Agent for Kubernetes available on GitLab.com

GitLab Agent for Kubernetes available on GitLab.com

The GitLab Agent for Kubernetes is finally available on GitLab.com. By using the Agent, you can benefit from fast, pull-based deployments to your cluster, while GitLab.com manages the necessary server-side components of the Agent. The Agent is the core building block of GitLab’s Kubernetes integrations. The Agent-based integration today supports pull-based deployments and Network Security policy integration and alerts, and will soon receive support for push-based deployments too.

Unlike the legacy, certificate-based Kubernetes integration, the Agent does not require opening up your cluster towards GitLab and allows fine-tuned RBAC controls around GitLab’s capabilities within your clusters.

Compliance pipeline configurations

Compliance pipeline configurations

We are thrilled to announce that it is now possible to define enforceable pipelines that will run for any project assigned a corresponding compliance framework.

For teams looking to implement compliance requirements in the pipeline workflow, they can now enforce even more separation of duties by setting up a single pipeline definition for a specific compliance framework. All projects using that framework will include the predefined pipeline automatically. Users extend, but cannot modify, the pipeline configuration in the downstream projects, ensuring that compliance steps are run the same way every time.

This saves security and compliance teams time by eliminating the need to manually copy a pipeline configuration to every project that needs it and then monitoring to prevent edits or removal. It also helps development teams follow policies without requiring them to become experts in compliance.

Defining a compliance pipeline configuration for compliance frameworks is a great way to ensure an organization consistently meets its regulatory requirements while saving everyone time and encouraging collaboration between security/compliance and development teams.

Check out the video walkthrough to see its setup and implementation!

Create custom compliance framework labels

Create custom compliance framework labels

GitLab currently provides several predefined compliance framework labels such as GDPR, HIPAA, PCI-DSS, SOC 2, and SOX. With this release, you can now add your own custom frameworks. This enables you to customize your labels for your own specific frameworks and processes. In the future, you will be able to create policies that can be applied to projects based on this label.

Create custom compliance framework labels

On-call Schedule Management

On-call Schedule Management

Software services do not get “turned off” at the end of the business day. Your customers expect 24/7 availability. When things go wrong, you need a team (or multiple teams!) that can quickly and effectively respond to service outages.

Being on-call can be a stressful job. To better manage stress and burn-out, most teams rotate this on-call responsibility. GitLab’s on-call schedule management allows you and your team to create and manage schedules for on-call responsibilities. Alerts received in GitLab through an HTTP endpoint are routed to the on-call engineer in the schedule for that specific project.

Re-authenticate for GitLab administration with Admin Mode

Re-authenticate for GitLab administration with Admin Mode

GitLab now includes Admin Mode, which helps admins work safely from one account. When Admin Mode is not active, admins have the same privileges as regular users. Before running administrative commands, admin users must reverify their credentials. Admin mode increases instance security by protecting sensitive operations and data.

Thank you Diego Louzán from Siemens for this contribution. Admin Mode wouldn’t have happened without his perseverance. This feature has been in the making for a year!

Re-authenticate for GitLab administration with Admin Mode

Export a user access report

Export a user access report

Compliance-minded organizations have a recurring requirement to audit the access their users have to company systems and resources. Previously, achieving this in GitLab required building custom tooling with our audit-related APIs to assemble the data you needed.

Now, you can simply click an export button in the admin area of your self-managed GitLab instance to retrieve a CSV file containing a list of each user and the groups, subgroups, and projects they have access to. It is now much easier to audit your user access in a lot less time.

Export a user access report

Use multiple caches in the same job

Use multiple caches in the same job

GitLab CI/CD provides a caching mechanism that saves precious development time when your jobs are running. Previously, it was impossible to configure multiple cache keys in the same job. This limitation may have caused you to use artifacts for caching, or use duplicate jobs with different cache paths. In this release, we provide the ability to configure multiple cache keys in a single job which will help you increase your pipeline performance.

Use multiple caches in the same job

Track DORA 4 lead time for changes metric

Track DORA 4 lead time for changes metric

Measuring the efficiency of your software development lifecycle is an important step to grow DevOps adoption for any organization. In the previous milestone, we added API support for lead time for changes at the project level. These metrics give you an indication of throughput so you know how long it takes for code to be committed and deployed to your production environment. In this release, you can now access this capability in the GitLab UI through the CI/CD dashboard, where a new graph will show the lead time for changes with the ability to view different time ranges, such as the last week, last month, or the last 90 days. In addition to the new graph, we have also added support for this API on the group level, allowing you to get aggregated lead time for changes metrics from all the projects that belong to the group.

Track DORA 4 lead time for changes metric

GitLab + Semgrep: upgrading SAST for the future

GitLab + Semgrep: upgrading SAST for the future

GitLab SAST historically has been powered by over a dozen open-source static analysis security analyzers. These analyzers have proactively identified millions of vulnerabilities for developers using GitLab every month. Each of these analyzers is language-specific and has different technology approaches to scanning. These differences produce overhead for updating, managing, and maintaining additional features we build on top of these tools, and they create confusion for anyone attempting to debug.

The GitLab Static Analysis team is continuously evaluating new security analyzers. We have been impressed by a relatively new tool from the development team at r2c called Semgrep. It’s a fast, open-source, static analysis tool for finding bugs and enforcing code standards. Semgrep’s rules look like the code you are searching for; this means you can write your own rules without having to understand abstract syntax trees (ASTs) or wrestle with regexes.

Semgrep’s flexible rule syntax is ideal for streamlining GitLab’s Custom Rulesets feature for extending and modifying detection rules, a popular request from GitLab SAST customers. Semgrep also has a growing open-source registry of 1,000+ community rules.

We are in the process of transitioning many of our lint-based SAST analyzers to Semgrep. This transition will help increase stability, performance, rule coverage, and allow GitLab customers access to Semgrep’s community rules and additional custom ruleset capabilities that we will be adding in the future. We have enjoyed working with the r2c team and we cannot wait to transition more of our analyzers to Semgrep. You can read more in our transition epic, or try out our first experimental Semgrep analyzers for JavaScript, TypeScript, and Python.

We are excited about what this transition means for the future of GitLab SAST and the larger Semgrep community. GitLab will be contributing to the Semgrep open-source project including additional rules to ensure coverage matches or exceeds our existing analyzers.

GitLab + Semgrep: upgrading SAST for the future

Support for custom CA certificates when using the release CLI

Support for custom CA certificates when using the release CLI

Up to this point in time, if you were using GitLab self-managed, you could use the release CLI with a public certificate, but not your own custom one. In GitLab 13.11, we have added support for custom certificate authority (CA) certificates by using the ADDITIONAL_CA_CERT_BUNDLE environment variable or the --additional-ca-cert-bundle flag. In addition, the INSECURE_HTTPS environment variable and the --insecure-https flag were added so that the client can skip verifying the server certificates, which would normally fail with a custom SSL certificate because it is not signed by a public CA.

Support for custom CA certificates when using the release CLI

Instance and group description templates for issues and merge requests

Instance and group description templates for issues and merge requests

Instead of manually updating the same description template across dozens of projects, you can now centrally manage and source your templates from a single repository. We’ve extended the instance and group file templates to include issue and merge request description templates. When you create a .gitlab directory in your file templates repository, description templates will be available to all projects that belong to the instance or group. Each group or subgroup can also set an additional template repository, which will enable templates from multiple file template repositories to cascade down to your subgroups and projects.

Instance and group description templates for issues and merge requests

Optional DAG (‘needs:’) jobs in CI/CD pipelines

Optional DAG (‘needs:’) jobs in CI/CD pipelines

The directed acyclic graph (DAG) in GitLab CI/CD lets you use the needs syntax to configure a job to start earlier than its stage (as soon as dependent jobs complete). We also have the rules, only, or except keywords, which determine if a job is added to a pipeline at all. Unfortunately, if you combine needs with these other keywords, it’s possible that your pipeline could fail when a dependent job does not get added to a pipeline.

In this release, we are adding the optional keyword to the needs syntax for DAG jobs. If a dependent job is marked as optional but not present in the pipeline, the needs job ignores it. If the job is optional and present in the pipeline, the needs job waits for it to finish before starting. This makes it much easier to safely combine rules, only, and except with the growing popularity of DAG.

Optional DAG ('needs:') jobs in CI/CD pipelines

Environment-specific variables at the group level

Environment-specific variables at the group level

Many organizations prefer to specify secrets and other environment variables at the group level, as it aligns well with team boundaries or trust levels. Until now, the group-level environment variables affected all the environments, and this limited their usability in a lot of use cases. Today, we are releasing environment-specific variables at the group level.

This change complements similar functionality at the project level. From now on, group maintainers can specify the environments where a given variable is to be applied.

Environment-specific variables at the group level

Request a CVE ID from the GitLab UI

Request a CVE ID from the GitLab UI

GitLab believes in responsibly disclosing software vulnerabilities. Since early 2020, GitLab has served as a CVE Numbering Authority (CNA) and can provide CVE IDs to security researchers and information technology vendors either for GitLab itself or for any project hosted on GitLab.com.

With GitLab 13.11 we’re making it easier for project maintainers to request CVE IDs from GitLab via our UI. On confidential issues in public projects hosted on GitLab.com, maintainers will see the ability to request a CVE ID in the right-hand sidebar. Clicking the ‘Request CVE ID’ button in the issue sidebar takes you to the new issue page for the GitLab CVE project where you can complete the request template and trigger the request workflow.

This feature can also be disabled on the project settings page should a project owner not want their repositories to offer this capability to maintainers. We are currently rolling out this feature slowly to GitLab.com hosted projects. You can follow our rollout progress issue for updates or provide feedback.

Request a CVE ID from the GitLab UI

Deploy GitLab on OpenShift and Kubernetes with the GitLab Operator (beta)

Deploy GitLab on OpenShift and Kubernetes with the GitLab Operator (beta)

GitLab is working to offer full support for OpenShift. To accomplish this, we have released the MVP GitLab Operator. The operator aims to manage the full lifecycle of GitLab instances on Kubernetes and OpenShift container platforms. Currently, this is a beta release and it is not recommended for production use. The next steps will be to make the operator generally available (GA). In the future the operator will become the recommended installation method for Kubernetes and OpenShift, although the GitLab Helm chart will still be supported. We welcome you to try this operator and provide feedback on our issue tracker.

Deploy GitLab on OpenShift and Kubernetes with the GitLab Operator (beta)

13.11 Other improvements in GitLab 13.11

Audit Events now available to Developer+

Audit Events now available to Developer+

Audit logs are one of the most important elements of a system for compliance-minded organizations and their compliance programs. The audit logs provide visibility into user and system activity to help troubleshoot incidents, isolate who was responsible for an action, and allow organizations to compile evidence artifacts for auditors of certain processes. Previously, only Maintainers, Owners, and Administrators could access the Audit Events view. All other users were unaware these logs existed and did not have access to view their own activity, let alone maintain a compliance mindset within their organization.

Security & Compliance > Audit Events is now available to users with Developer access and higher. Users with Developer access can only see their own activity, not the activity of other users (users with Maintainer access and higher continue to see both their own activity and the activity of other users). This change makes audit data accessible to more users and helps strengthen the compliance mindset of GitLab users.

GPG keys available in the admin Credential Inventory

GPG keys available in the admin Credential Inventory

You can now view GPG key information for your users in the admin area. This lets you quickly see what keys are stored in GitLab, their ID, and if they are verified or not, to help you better understand how users could interact with your GitLab instance.

This is part of our continuing efforts to build out the Credential Inventory. We have many iterations planned to add more visibility, control, and value for your organization. We’d love your feedback on the epics and issues!

GPG keys available in the admin Credential Inventory

Register OAuth applications at the group level

Register OAuth applications at the group level

Group owners can now register OAuth applications for a group. Previously, OAuth applications could only be registered by individual users or at the instance level. Making this functionality available at the group level reduces the administrative burden for instance administrators and removes the dependency on individual users for the configuration of OAuth applications.

Thanks to the amazing work from GitLab contributor Jonas Wälter from Siemens, this feature is now available in 13.11.

Add iteration lists in Boards

Add iteration lists in Boards

Boards now support creating iteration lists. Quickly move issues from one iteration to another on your planning board or enable epic swimlanes to efficiently sequence an epic’s issues across your upcoming iterations.

Add iteration lists in Boards

Active integrations now display separately

Active integrations now display separately

With over 30 integrations available today, it was becoming difficult to see which integrations were currently active on the settings page.

Active integrations now display in a separate table at the top of the page, making it clear what you’re using, and easier to find the integrations you care about most.

Active integrations now display separately

Cherry pick commits from fork to parent

Cherry pick commits from fork to parent

With GitLab 13.11, if you are a project member, you can now cherry-pick commits from downstream forks back into your project. We’ve added a new Pick into project section to the cherry-pick dialog, shown when you select Options > Cherry-pick on a commit’s details page.

Your community of contributors can contribute to your project, and your team no longer needs to manually download a fork’s .patch file to pull in good changes from stale or unmaintained forks.

Future enhancements include cherry-picking commits from fork to fork.

Cherry pick commits from fork to parent

Force push option for protected branches

Force push option for protected branches

It’s best practice to prevent force push on Git repos, but exceptional cases may occasionally require it. Temporarily removing branch protections in order to conduct a force push may not always be ideal as it requires maintainer access, and causes the settings for branch protection to be lost.

GitLab 13.11 introduces a new Allow force push setting for protected branches, which enables users in the Allowed to push list to force push.

Force push option for protected branches

Search within a settings page

Search within a settings page

Finding the exact location of a GitLab setting can be challenging. Even if you know generally where to look, many of the settings views have multiple sections and dozens of individual configuration options.

In this release, you can now use the search field in group, project, admin, and user settings to quickly pinpoint your desired configuration. Your search criteria will filter the current page down to display only relevant settings and even highlight occurrences of your search term on the page.

In the future iterations, we are looking to extend this functionality to search across all settings views.

Search within a settings page

Welcome view for GitLab Workflow in VS Code

Welcome view for GitLab Workflow in VS Code

Getting started with the GitLab Workflow extension for Visual Studio Code (VS Code) requires several manual steps to connect it to GitLab. If the extension isn’t set up correctly, or you’re setting it up for the first time, it can be hard to verify you’ve configured it correctly.

In the GitLab Workflow pane inside VS Code, there are now steps to help you get started. It also tells you if your current workspace doesn’t contain a GitLab project.

Welcome view for GitLab Workflow in VS Code

Create initial configuration file from the pipeline editor

Create initial configuration file from the pipeline editor

The pipeline editor is your one stop shop to build and test your CI/CD pipeline. Previously, the editor only worked if the .gitlab-ci.yml configuration file already existed in the root of your repository. In this release, we’ve added the ability to create an initial empty pipeline file from the pipeline editor page itself, so you can start authoring your pipeline immediately.

Create initial configuration file from the pipeline editor

Predefined CI/CD variable for commit author

Predefined CI/CD variable for commit author

Previously, if you needed to identify the author of a commit in a running CI/CD job, you had to add an extra API call to the job to retrieve it. Now, this information is readily available as the CI_COMMIT_AUTHOR predefined CI/CD variable.

Thanks to Craig Andrews for this contribution!

Publish and install generic packages with SemVer

Publish and install generic packages with SemVer

You use the GitLab Package Registry to publish and share generic package files. You can do this using the command line, but it’s likely that you use GitLab CI/CD to publish most of your files.

Prior to GitLab 13.11, the GitLab validation on the file name prevented you from uploading a package with a semantic version (SemVer). This blocked many of you from using the Package Registry in your pipelines since SemVer is commonly used to mark files as related to a given release or branch.

GitLab 13.11 relaxes the file name validation so you can use SemVer to name files. We hope this helps you to adopt the Package Registry and makes it easier to name, validate, and verify your generic packages.

Use Composer v2 with the GitLab Package Registry

Use Composer v2 with the GitLab Package Registry

You use Composer to publish, share, and download your PHP dependencies to your GitLab Project. Six months ago, a new major version (v2) of Composer was launched with a variety of changes, including significant performance improvements, architectural updates, and runtime features. You can read more about the changes here.

Until recently, you couldn’t take advantage of these improvements because the GitLab registry didn’t support Composer v2. This prevented some of you from using the GitLab registry at all. As an MVC, we focused on adding support for the mandatory parameter metadata-URL. We added a new endpoint GET group/:id/-/packages/composer/p2/:package_name, which returns the metadata for all packages in your repository. When Composer looks for a package, it replaces %package% with the package name and fetches that URL.

This means we’ve added a new endpoint GET group/:id/-/packages/composer/p2/:package_name which will return the metadata for all packages in your repository.

Please note that there are two parameters considered optional. We have issues open to add support for the providers-api and list-api parameters. We hope to prioritize them in an upcoming milestone.

Update a deploy freeze period in the UI

Update a deploy freeze period in the UI

In GitLab 13.2, we added the ability to create a deploy freeze period in the project’s CI/CD settings. This capability helps teams avoid unintentional deployments, reduce uncertainty, and mitigate deployment risks. However, it was not possible to update deploy freezes. In GitLab 13.11, we are adding the ability to edit an existing deploy freeze. This way, you can update the freeze period to match your business needs.

Update a deploy freeze period in the UI

GitLab chart improvements

GitLab chart improvements

  • The configuration option terminationGracePeriodSeconds in Sidekiq is now available for the Sidekiq chart, which allows for better protection of long-running jobs during pod shutdown.
  • Previously, there was no protection if users set the SIDEKIQ_TIMEOUT to a value higher than terminationGracePeriodSeconds. This would result in jobs that are continuing to run beyond 30 seconds to be forcibly stopped. With the new chart release, Sidekiq deployments can now have differing timeouts.
  • Support for IAM roles for service accounts to access external object storage is now available.

Experimental Semgrep Analyzer for Python, JavaScript, and TypeScript

Experimental Semgrep Analyzer for Python, JavaScript, and TypeScript

As part of our partnership with Semgrep to power the future of GitLab SAST, we are seeking beta testers to try our new Semgrep analyzer for Python, JavaScript, and TypeScript. These experimental analyzers run alongside our existing Python, JavaScript, and TypeScript analyzers such that you can compare vulnerabilities detected between the various analyzers.

  • Our new Semgrep analyzer for Python will eventually replace our existing Python analyzer, Bandit. As part of this transition, our team has evaluated rule coverage for both tools to ensure that we maintain detection coverage.
  • Our new Semgrep analyzer for JavaScript and TypeScript will eventually replace our existing analyzer, ESLint. We currently are aware of a gap in detection coverage with ESLint that we are working with the Semgrep team to resolve.

To run either of these analyzers, you’ll need to enable the experimental SAST flag within your ‘gitlab-ci.yml’ configuration file which will allow the new Semgrep analyzers to run alongside any existing SAST analyzers. Please note, currently, we have not completed remapping vulnerability findings between the analyzers, so you may see duplicated findings in your security report. This will be resolved before we complete this transition. We welcome any feedback or suggestions on these analyzers in the respective linked issues above.

Static Analysis Analyzer Updates

Static Analysis Analyzer Updates

GitLab Static Analysis is comprised of a set of many security analyzers that the GitLab Static Analysis team actively manages, maintains, and updates. Below are the analyzer updates released during 13.11. These updates bring additional coverage, bug fixes, and improvements.

  • ESLint updated to version 7.23.0: MR, Changelog
  • MobSF updated to version 3.4.0: MR, Changelog
  • njsscan updated to version 0.2.3: MR, Changelog
    • notable change: njsscan max file size has reduced from 25Mb to 5Mb. New Sequelize rules.
  • gitleaks updated to version 0.2.3: MR, Changelog
    • notable change: New PyPI and GitHub secret detection rules.

If you are including the GitLab managed vendored SAST template (SAST.gitlab-ci.yml) you do not need to do anything to receive these updates. However, if you override or customize your own CI template, you will need to update your CI configurations.

DevOps Adoption metrics available at the group level

DevOps Adoption metrics available at the group level

The DevOps adoption table is a valuable feature for leadership to see which GitLab stages and features have been adopted by their teams. Up until this point, this feature could only be accessed through the Admin Area, which restricted access to administrators on self-managed instances of GitLab. This update brings DevOps adoption metrics to the group level, allowing more users to understand how and where they are adopting features across GitLab. This feature is currently disabled by default. To enable it, see instructions in the documentation. It will be enabled by default in the next release.

DevOps Adoption metrics available at the group level

Group SAML Enforcement for Git activity

Group SAML Enforcement for Git activity

GitLab group maintainers can now enhance their group security by enforcing Group SAML for Git activity. Security-minded organizations want all GitLab activity to be protected and governed by their SAML Identity Provider. Currently, SAML SSO enforcement only applies to activity in the GitLab UI. Git CLI operations do not require an active SAML SSO session. When Git Group SAML SSO enforcement is enabled, users must have an active web SAML session to perform Git operations in the CLI.

SSH key expiration email notification

SSH key expiration email notification

SSH keys that you add to the Credential Inventory can be configured with an expiration date to help ensure proper key rotation and limit ongoing access to your instance.

By default, GitLab will now check daily to see if any expiration dates are approaching. An email notification will be sent the week before, and the day before the key expires, to allow you to take any needed actions to update the key or any systems that rely on it.

Filter requirements based on status

Filter requirements based on status

To know which areas of the product need additional testing or are incomplete, you can now filter your requirement list based on the status. Now, you and your team can readily see what work remains!

As requirements can be satisfied through CI/CD pipeline jobs, the status of the requirement is always up to date.

Filter requirements based on status

Add standalone comments to merge request reviews

Add standalone comments to merge request reviews

When you’re reviewing changes, you may want to summarize your feedback, or comment on something unrelated to the specific changes. Reviews in GitLab only allowed commenting on the changes or replying to existing comments, which meant that other kinds of comments had to be made after submitting the review.

As part of your review process, you can now submit a general comment along with your replies or change-specific comments. General comments make it simple to provide feedback to the author and use quick actions to update items across the merge request.

Thanks to Lee Tickett for the contribution!

Add standalone comments to merge request reviews

Collaborating on long files is easier when you can share a link to a specific line of code. Previously, you could only link to a line number when viewing a file in the repository, but now you can also link to specific lines of code in the context of editing a file. Previously announced in GitLab 13.10 for SaaS customers, this feature is now available to everyone.

To get a link to a specific line, click the icon in the gutter next to the line number, or append #L followed by the line number to the edit URL. The link will open the editor, scroll to the line, and highlight it for you. Try it out in the single-file editor, the Web IDE, and the Pipeline Editor!

Tip: you can even create a link to multiple lines by appending a range to the link, like #L87-98, even though the UI doesn’t support creating these (yet).

Deep link directly to lines of code

Improvements to Jira Connect application configuration

Improvements to Jira Connect application configuration

When configuring the GitLab.com for Jira application, you can now filter the available namespaces when linking them to your account, simplifying configuration for users with access to a large number of namespaces.

Improvements to Jira Connect application configuration

Set default target project for merge requests in forks

Set default target project for merge requests in forks

After forking a project, it can be beneficial to use merge requests to make contributions to the upstream project. Previously, GitLab assumed that merge requests from your fork project would always target the upstream project. This can create missteps where code shouldn’t be merged upstream, or users need to make changes prior to opening the merge request.

GitLab now supports setting the default target project for merge requests that are created in fork projects. This streamlines contributions and helps avoid mistakes for users and teams who more commonly contribute to their fork project, instead of the upstream project.

Set default target project for merge requests in forks

Code Quality violations sorted by severity

Code Quality violations sorted by severity

Running Code Quality scans on your Projects can find dozens to thousands of violations. In the smaller view of the Merge Request widget, it can be hard to pinpoint the most critical issues to address first as you’re sorting through a large number of code quality violations.

Both the Code Quality Merge Request widget and the Full Code Quality Report now sort violations by Severity so that you can quickly identify the most important Code Quality violations to address.

Code Quality violations sorted by severity

GitLab Runner 13.11

GitLab Runner 13.11

We’re also releasing GitLab Runner 13.11 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.

Download Composer dependencies from version control

Download Composer dependencies from version control

You have two options when downloading Composer dependencies: source or dist. For stable versions, Composer uses dist by default and downloads the dependency as a zip file. However, you can also download it directly from version control. If --prefer-source is enabled, Composer downloads your dependency as a Git clone instead of as a packaged zip file. This is useful if you want to make a bug fix for a project and get a local Git clone of the dependency directly.

Until recently, you could not use the prefer-source and related preferred-install commands and configurations when downloading Composer dependencies. This prevented many of you from using the GitLab Package Registry for your Composer dependencies.

We are happy to announce that you can now download your Composer dependencies from source. Do so by simply adding the prefer-source option to your install command like this: composer update --prefer-source.

Share filtered views of the Package and Container Registries

Share filtered views of the Package and Container Registries

You use the GitLab Package and Container registries to publish and share your project’s dependencies. When you view your registry in GitLab, you can filter and sort the results to find and validate the item you are looking for.

Before GitLab 13.11, you had no way to share a filtered view of the registry with your teammates. As a result, each team member had to spend time filtering their view. This was inefficient and introduced the risk that the wrong dependency may be installed.

In GitLab 13.11, you can share your filtered view of the registry by simply copying the URL from your browser and sharing it with your team. We hope this change makes you more efficient.

Bring your own Prometheus for the best GitLab - Kubernetes integrated experience

Bring your own Prometheus for the best GitLab - Kubernetes integrated experience

By integrating your cluster services with GitLab you can benefit from various GitLab features, like Environment boards, Prometheus metrics, and application logs. Previously, these features required you to use GitLab Managed Apps which did not suit the workflow and requirements of many of our users.

With this release, you can integrate with Prometheus and Kubernetes through GitLab services and keep their maintenance on your end, following your own company processes and policies. We provide extensive documentation and a recommended workflow on how to install these applications if you are just getting started. You can still hold the deep metrics integrations available in GitLab as you had with GitLab Managed Prometheus.

Geo supports Pipeline Artifacts

Geo supports Pipeline Artifacts

Geo now supports replicating and verifying Pipeline Artifacts to secondary sites, allowing distributed teams to access them from the closest Geo site, which reduces latency and improves the overall user experience. Geo automatically verifies the data integrity of replicated Pipeline Artifacts. This ensures that Pipeline Artifacts are not corrupted in transfer or at rest. If Geo is used as part of a disaster recovery strategy, this protects customers against data loss.

Omnibus improvements

Omnibus improvements

GitLab 13.11 includes Mattermost 5.33, which includes a soft delete when deleting a reaction in the reactions table. Also WebSocket handshakes done with HTTP version lower than 1.1 will result in a warning, and the server will transparently upgrade the version to 1.1 to comply with the WebSocket RFC. This facility will be removed in a future Mattermost version and it is strongly recommended to fix the proxy configuration to correctly use the WebSocket protocol.

OpenShift Support for SAST and Secret Detection

OpenShift Support for SAST and Secret Detection

Since 13.3, GitLab has supported runners on Red Hat OpenShift. Until now, GitLab Security scans did not support this deployment option. With 13.11, GitLab SAST and Secret Detection security analyzers can now operate within an OpenShift deployment. If you have overridden or provide a custom .gitlab-ci.yml file with pinned versions of SAST or Secret Detection analyzers please update to the latest available versions. Please note that experimental analyzers do not currently support OpenShift environments. As these analyzers are promoted from experimental status, feature completeness will be added.

Support for Generic Kotlin SAST Scanning

Support for Generic Kotlin SAST Scanning

Since 13.5, GitLab Static Application Security Scanning (SAST) has supported scanning mobile projects including Android applications written in Kotlin. However, this Kotlin scanning only focused on mobile application security risks. In GitLab 13.11, thanks to a community contribution by core team member Hannes Rosenögger (@haynes), our existing Java analyzer Spotbugs now supports scanning generic Kotlin projects and files. As Kotlin grows in popularity and slowly replaces Java in more modern projects, GitLab SAST continues to help developers ensure they are writing secure code.

Bug Fixes

Bug Fixes

Some of the notable bug fixes in 13.11 are:

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.11, we’re shipping performance improvements for issues, projects, milestones, and much more! Some improvements in GitLab 13.11 are:

Usability Improvements

Usability Improvements

In every release, we make great strides in improving the overall effectiveness and usefulness of our product.

We also have a UI Polish Gallery to track important updates to our interfaces. These updates, while often small, improve your user experience.

In GitLab 13.11, we’re shipping usability improvements for issues, projects, milestones, and much more! We highlight the following changes in GitLab 13.11:

Deprecations Deprecations

All CI/CD stages removed from the fuzz testing default template

All CI/CD stages removed from the fuzz testing default template

In GitLab 14.0, the stages defined in the current API-Fuzzing.gitlab-ci.yml template will be removed to avoid the situation where the template overrides manual changes made by users of fuzz testing. This change is being made in response to customer issues where the stages in the template caused problems when used with customized fuzz testing configurations. Because of this removal, .gitlab-ci.yml configurations that do not specify a fuzz stage must be updated to include this stage.

In GitLab 13.11, the stages are deprecated so they’ve been removed from the API-Fuzzing.latest.gitlab-ci.yml template. Anyone can test and see if any changes are needed in their configuration files.

Planned removal date: Jun 22, 2021

Auto DevOps: Stable Auto Deploy template renewal

Auto DevOps: Stable Auto Deploy template renewal

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 backward 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

CI/CD pipeline behavior changes in GitLab 14.0

CI/CD pipeline behavior changes in GitLab 14.0

In GitLab 14.0, we intend to make some changes to the behavior of CI/CD pipelines to improve performance and resource usage:

  • Scheduled pipeline that run very frequently can impact an instance’s performance. In GitLab 14.0, the frequency of scheduled pipelines will be subject to GitLab application limits. For self-managed instances, admins will have the option to change or disable these limits, which can reduce the problems caused by performance-impacting cron patterns in pipeline schedules.
  • In some edge cases, users were accidentally triggering both branch pipelines and merge request pipelines at the same time, wasting resources. We are working to add a default workflow: rule in GitLab 14.0 to reduce the risk of this happening. Users with pipelines configured to rely on this behavior can easily override the new default with their own workflow: rule to re-enable the previous behavior.

Planned removal date: June 22, 2021

Code Quality Rubocop support changing

Code Quality Rubocop support changing

Currently, by default, the Code Quality feature does not provide support for Ruby 2.6+ if you’re using the Code Quality template.

To better support the latest versions of Ruby, the default Rubocop version is being changed to add support for Ruby 2.4 through 3.0. As a result, support for Ruby 2.1, 2.2, and 2.3 will be dropped. You can reenable support for older versions by customizing your configuration.

Relevant Issue: Default codeclimate-rubocop engine does not support Ruby 2.6+

Planned removal date: June 22, 2021

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. Clair was deprecated in GitLab 13.9. 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

DAST environment variable renaming and removal

DAST environment variable renaming and removal

GitLab 13.8 renamed multiple CI/CD variables to support their broader usage in different workflows. In GitLab 14.0, the old variables will be permanently removed and will no longer work. Any configurations using these variables must be updated to the new variable names. Any scans using these variables in GitLab 14.0 and later will fail to be configured correctly. These variables are:

  • DAST_AUTH_EXCLUDE_URLS becomes DAST_EXCLUDE_URLS.
  • AUTH_EXCLUDE_URLS becomes DAST_EXCLUDE_URLS.
  • AUTH_USERNAME becomes DAST_USERNAME.
  • AUTH_PASSWORD becomes DAST_PASSWORD.
  • AUTH_USERNAME_FIELD becomes DAST_USERNAME_FIELD.
  • AUTH_PASSWORD_FIELD becomes DAST_PASSWORD_FIELD.
  • DAST_ZAP_USE_AJAX_SPIDER becomes DAST_USE_AJAX_SPIDER.
  • DAST_FULL_SCAN_DOMAIN_VALIDATION_REQUIRED will be removed, since the feature is being removed.

Planned removal date: Jun 22, 2021

Default Browser Performance testing job will be renamed in GitLab 14.0

Default Browser Performance testing job will be renamed in GitLab 14.0

Browser Performance Testing currently runs in a job named performance by default. With the introduction of Load Performance Testing in GitLab 13.2, this naming could be confusing.

To make it clear which job is running Browser Performance Testing, the default job name will be changed from performance to browser_performance in the template in GitLab 14.0.

Relevant Issue: Rename default Browser Performance Testing job

Planned removal date: June 22, 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 legacy Gitaly Cluster primary electors

Deprecate legacy Gitaly Cluster primary electors

Now that Praefect supports a per_repository primary election strategy to elect a primary for each repository, we will be deprecating the legacy strategies in GitLab 13.12 so we can remove them in GitLab 14.0.

  • The local elector is not supported in production, so should not impact production instances.
  • The sql elector is incompatible with the [variable replication factor] (https://docs.gitlab.com/ee/administration/gitaly/praefect.html#configure-replication-factor) functionality.

For anyone using local or sql primary electors, we recommend you update to the per_repository election strategy as soon as possible. See the migration documentation.

Planned removal date: Jun 22, 2021

Deprecating Global SAST_ANALYZER_IMAGE_TAG in SAST CI template

Deprecating Global SAST_ANALYZER_IMAGE_TAG in SAST CI template

With the maturity of GitLab Secure scanning tools, we’ve needed to add more granularity to our release process. Currently, GitLab shares a major version number for all our analyzers and tools. This requires all tools to share a major version and prevent the use of semantic version numbering. Beginning in 14.0 GitLab SAST will deprecate the SAST_ANALYZER_IMAGE_TAG global variable in our managed SAST.gitlab-ci.yml CI template in favor of the analyzer job variable setting the ‘major.minor’ tag in the SAST vendored template. Each analyzer job will have a scoped SAST_ANALYZER_IMAGE_TAG variable which will be actively managed by GitLab and set to the ‘major.minor’ tag for the respective analyzer. To pin to a specific version you simply change the variable value to the specific version tag. If you override or maintain custom versions of SAST.gitlab-ci.yml you will want to update your CI templates to stop referencing the global SAST_ANALYZER_IMAGE_TAG and move it to a scoped analyzer job tag. 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 more granular control future analyzer updates. This change will happen with GitLab 14.0 releasing June 22, 2021. This deprecation and planned removal changes our previously announced plan to Pin the Static Analysis tools.

Planned removal date: June 22, 2021

Deprecation of legacy storage for GitLab Pages

Deprecation of legacy storage for GitLab Pages

To make GitLab Pages cloud-native compatible, starting in GitLab 14.0, we’re changing the underlying storage architecture used by GitLab Pages to the recently introduced ZIP storage.

Your migration to the new zip archives architecture is designed to be automatic. However, if after the migration, some Pages stop working (you see a 404), it likely means automatic migration failed. To ease this transition to zip, a temporary flag gitlab_pages['use_legacy_storage'] = true will be available from GitLab 14.0 to 14.3, but it will be removed in GitLab 14.4. This flag will allow GitLab and GitLab Pages to use the non-zip deployments to serve content.

In GitLab 13.11 & GitLab 13.12 you will be able to migrate to the new architecture earlier and test it in your environment prior to 14.0.

Planned removal date: June 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

We are reiterating the deprecations coming up in 14.0, as mentioned in 13.9 and this blog post.

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.

Previously to prevent the Gemnasium analyzers to fetch the advisory database at runtime, you needed to set the GEMNASIUM_DB_UPDATE variable. 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.

Planned removal date: June 22, 2021

Drop updated_at filter from Deployment API

Drop updated_at filter from Deployment API

Some users are pulling data from the list project deployments API endpoint to populate a custom-built dashboard. There is no way to restrict the API results to display only the latest changes. To overcome this, one must retrieve all records, check one-by-one and process only the records updated after the latest updated_at value in the last batch retrieved. In order to make this process more efficient and performant, this API will change in GitLab 14.0. Using the updated_after and updated_before in this API will result in an error. These fields will be replaced by ‘finished_after’ and ‘finished_before. In addition, when the ‘updated_at’ filter is specified, ‘order_by’ must be ‘updated_at’.

Planned removal date: June 22, 2021

Dropping support for SAST scanning of Go projects without Go modules enabled

Dropping support for SAST scanning of Go projects without Go modules enabled

As part of maintaining our Go SAST analyzer GoSec, we need to upgrade to Go 1.16. This means that we will no longer scan projects that do not have Go modules enabled, which drops support for Go versions prior to 1.11. If you require scanning of older Go projects you can override our managed CI templates and pin the Go analyzer to v2.20.0.

Planned removal date: June 22, 2021

External Pipeline Validation Service Code Changes

External Pipeline Validation Service Code Changes

GitLab sends a POST request to the external service URL with the pipeline data as payload. GitLab then invalidates the pipeline based on the response code. If there’s an error or the request times out, the pipeline is not invalidated. We are changing what codes are accepted:

Planned removal date: Jun 22, 2020

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

GitLab is deprecating the OAuth 2 implicit grant flow as it has been removed for OAuth 2.1.

Beginning in 14.0, new applications will be unable 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.

Users of the chart should upgrade to Helm v3 to deploy GitLab 14.0 and above.

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 finally 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. A complete list of projects can still be retrieved by using the GET /groups/:id/projects API call.

Planned removal date: June 22nd, 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 GitLab 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 variable 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 migrated 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. The CI/CD variable SAST_DEFAULT_ANALYZERS will be removed in GitLab 14.0, which will release on June 22, 2021.

Planned removal date: June 22, 2021

NFS for Git repository storage deprecated

NFS for Git repository storage deprecated

With the general availability of Gitaly Cluster (introduced in GitLab 13.0), we are deprecating support for NFS for Git repositories in GitLab 14.0.

We want to help you avoid purchasing expensive NFS appliances you won’t need, so invite customers currently using NFS for Git repositories to begin planning their migration.

We are pleased to provide documentation on Migrating to Gitaly Cluster.

To see our overall status, please review our Gitaly Cluster roadmap.

Planned removal date: June 22, 2021

One-click GitLab Managed Apps will be removed in GitLab 14.0

One-click GitLab Managed Apps will be removed in GitLab 14.0

We are deprecating one-click install of GitLab Managed Apps. Although they made it very easy to get started with deploying to Kubernetes from GitLab, the overarching community feedback was that they were not flexible or customizable enough for real-world Kubernetes applications. Instead, our future direction will focus on installing apps on Kubernetes via GitLab CI/CD in order to provide a better balance between ease-of-use and expansive customization.

We plan to remove one-click Managed Apps completely in GitLab version 14.0. This will not affect how existing managed applications run inside your cluster, however, you’ll no longer have the ability to modify those applications via the GitLab UI. We recommend cluster administrators plan to migrate any existing managed applications by reinstalling them either manually or via CI/CD. Migration instructions will be available in our documentation later.

For users of alerts on managed Prometheus, in GitLab version 14.0, we will also remove the ability to setup/modify alerts from the GitLab UI. This change is necessary because the existing solution will no longer function once managed Prometheus is removed.

Planned removal date: June 22, 2021

OpenSUSE Leap 15.1

OpenSUSE Leap 15.1

Support for OpenSUSE Leap 15.1 is being deprecated. Support for 15.1 will be dropped in 14.0. We are now providing support for openSUSE Leap 15.2 packages.

Planned removal date: June 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

Redis 4 deprecation

Redis 4 deprecation

In GitLab 12.7, the Redis version was updated to Redis 5. Redis 4 has reached end of life and will no longer be supported as of GitLab 14.0. If you are using your own Redis 4.x instance, you should upgrade it to Redis 5.x or 6.x before GitLab 14.0 is released.

Planned removal date: Jun 22, 2021

Removal of PipelineProcessWorker and PipelineUpdateWorker

Removal of PipelineProcessWorker and PipelineUpdateWorker

As part of the Pipeline Service refactoring, GitLab will be removing two legacy CI workers: build_ids parameter of PipelineProcessWorker and PipelineUpdateWorker.

Planned removal date: Jun 22, 2020

Removal of trace parameter from `PUT /api/jobs/:id

Removal of trace parameter from `PUT /api/jobs/:id

Previously, GitLab-Runner would send job trace in two scenarios: during a job is running (via PATCH /api/jobs/:id/trace) and when a job finished (via PUT /api/jobs/:id). We have updated GitLab-Runner to stop sending trace parameter in the second scenario, and will be removing the trace parameter from PUT /api/jobs/:id endpoint in GitLab-Rails.

Planned removal date: Jun 22, 2020

Removal of legacy fields from DAST report

Removal of legacy fields from DAST report

As a part of the migration to a common report format for all of the Secure scanners in GitLab, DAST is making changes to the DAST JSON report. Certain legacy fields are being deprecated in 13.8 and will be completely removed in 14.0. These fields are @generated, @version, site, and spider. This should not affect any normal DAST operation, but does affect users who consume the JSON report in an automated way and use these fields. Anyone impacted by these changes who needs these fields for business reasons is encouraged to open a new GitLab issue and explain the need.

For more information, see the removal issue.

Planned removal date: Jun 22, 2021

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 DAST default template stages

Remove DAST default template stages

In GitLab 14.0, the stages defined in the current DAST.gitlab-ci.yml template will be removed to avoid the situation where the template overrides manual changes made by DAST users. This change is being made in response to customer issues where the stages in the template cause problems when used with customized DAST configurations. Because of this removal, gitlab-ci.yml configurations that do not specify a dast stage must be updated to include this stage.

In GitLab 13.8, the stages are deprecated and the changes to remove them from the template are included in the DAST.latest.gitlab-ci.yml template. Anyone can test and see if any changes are needed in their configuration files.

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 GLOBAL_DEFAULT_BRANCH_NAME feature flag

Remove GLOBAL_DEFAULT_BRANCH_NAME feature flag

In GitLab release 13.12 we will remove the GLOBAL_DEFAULT_BRANCH_NAME feature flag. Refer to issue #325163 for details.

Planned removal date: May 22, 2021

Remove PUSH_RULES_SUPERSEDE_CODE_OWNERS feature flag

Remove PUSH_RULES_SUPERSEDE_CODE_OWNERS feature flag

In GitLab release 14.0 we will remove the PUSH_RULES_SUPERSEDE_CODE_OWNERS feature flag. Refer to issue #262019 for details.

Planned removal date: June 22, 2021

Remove SAST analyzer SAST_GOSEC_CONFIG variable in favor of custom rulesets

Remove 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 was deprecated in GitLab 13.10. 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: June 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 legacy DAST domain validation

Remove legacy DAST domain validation

Starting with GitLab 13.8, the current method of DAST Domain Validation for CI/CD scans is deprecated. In GitLab 14.0, the legacy DAST validation method will be removed. This method of domain validation only disallows scans if the DAST_FULL_SCAN_DOMAIN_VALIDATION_REQUIRED environment variable is set to true in the gitlab-ci.yml file, and a Gitlab-DAST-Permission header on the site is not set to allow. This two-step method created a situation in which users had to opt in to using the variable before they could opt out from using the header. For users concerned about protecting a site against a full, active scan, permission for a GitLab DAST scan can still be revoked by adding to any website a Gitlab-DAST-Permission header with a value of deny. This continues to block GitLab DAST scans attempted against any website that includes this HTTP header.

For more information, see the removal issue.

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 redundant key/value pair from the payload of DORA metrics API

Remove redundant key/value pair from the payload of DORA metrics API

The deployment frequency project level API endpoint has been deprecated in favor of the DORA 4 API, which consolidates all the metrics under one API with the specific metric as a required field. As a result, the timestamp field, which doesn’t allow adding future extensions and causes performance issues, will be removed. An example response would be { "2021-03-01": 3, "date": "2021-03-01", "value": 3 }. The first key/value ("2021-03-01": 3) will be removed and replaced by the last two ("date": "2021-03-01", "value": 3).

Planned removal date: June 22, 2021

Remove secret_detection_default_branch job

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 the script section 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 or Secret-Detection.gitlab-ci.yml, you must update your CI templates. We strongly encourage inheriting and overriding our managed CI templates to futureproof 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: June 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 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

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

Ubuntu 16.04 support

Ubuntu 16.04 support

Ubuntu 16.04 will reach end-of-life in April 2021, and no longer receive maintenance updates. We strongly recommend users to upgrade to a newer release, such as 20.04.

GitLab 13.12 will be the last release with Ubuntu 16.04 support.

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

Web Application Firewall (WAF)

Web Application Firewall (WAF)

GitLab’s Web Application Firewall (WAF) is deprecated in GitLab 13.6. As this is a breaking change, the WAF will be removed from the product on June 22, 2021 in GitLab 14.0. GitLab’s WAF had limitations inherent in the architectural design that made it difficult to meet the requirements traditionally expected of a WAF. By deprecating and removing the WAF, GitLab will be able to focus its efforts on furthering other areas in the product where more value can be provided to users. Users who currently rely on GitLab’s WAF can continue to use the free and open source modsecurity project which is independent from GitLab. Additional details are available in the deprecation issue.

Planned removal date: June 22nd, 2021

Removals and breaking changes Removals and breaking changes

Default DAST spider begin crawling at target URL

Default DAST spider begin crawling at target URL

In GitLab 14.0, DAST will remove the current method of resetting the scan to the hostname when starting to spider. Previous to GitLab 14.0, the spider would not begin at the specified target path for the URL but would instead reset the URL to begin crawling at the host root. In GitLab 14.0, the default for the new variable DAST_SPIDER_START_AT_HOST will be changed to false to better support users’ intention of beginning spidering and scanning at the specified target URL, rather than the host root URL. In addition to starting to crawl the specified URL, this will have an added benefit that scans could take less time, if the specified path does not contain links to the entire site. This will enable easier scanning of smaller sections of an application, rather than the entire app being crawled at every scan.

Removal date: Jun 22, 2021

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

HipChat integration no longer available

HipChat integration no longer available

We are removing HipChat integration from GitLab in version 14.0. HipChat was discontinued by Atlassian in 2018, and support reached end-of-life in June of 2020.

Removal date: Apr 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

Pipeline Graph structural update

Pipeline Graph structural update

In this release, you will notice an update to the pipeline graph view that improves performance and maintainability by simplifying the layout. In 13.11, the lines between jobs dependencies that were previously shown will not be displayed, which helps you to more quickly visualize your pipelines. We are also working to add more ways to visualize your pipelines in future releases.

Removal date: May 22, 2021

Removal of merge request approvers endpoint in favor of Approval Rules API

Removal of merge request approvers endpoint in favor of Approval Rules API

The PUT /projects/:id/merge_requests/:merge_request_iid/approvers API endpoint was deprecated and scheduled for removal on September 22, 2019 due to the release of Approval Rules. Approval rules for merge requests allow you to communicate who should participate in code reviews by specifying the eligible approvers, and the minimum number of approvals for each. GitLab 13.11 removes support for this endpoint. If you currently use this endpoint, read the documentation to learn how to implement the feature using the Approval Rules API.

Removal date: April 22, 2021

Removal of project approvers endpoint in favor of Approval Rules API

Removal of project approvers endpoint in favor of Approval Rules API

The PUT /projects/:id/approvers API endpoint was deprecated and scheduled for removal on September 22, 2019 due to the release of Approval Rules. Approval rules for merge requests allow you to communicate who should participate in code reviews by specifying the eligible approvers, and the minimum number of approvals for each. GitLab 13.11 removes support for this endpoint. If you currently use this endpoint, read the documentation to learn how to implement the feature using the Approval Rules API.

Removal date: April 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.

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.

Removal date: June 22, 2021

project-ref-sha repo archival route removal

project-ref-sha repo archival route removal

Prior to GitLab 10.7 the method used to archive repositories returned an archive named project-ref-sha and a parent directory of the same name. This made the process of packaging releases more difficult as you had to know both the tag and the SHA.

GitLab 10.7 added the project-ref route which simplifies packaging by adding a route that returns an archive project-ref.

The old project-ref-sha has been removed in GitLab 13.11.

Removal date: April 22, 2021

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
Edit this page View source