13.8

GitLab 13.8 Release

GitLab 13.8 released with a Pipeline Editor and DORA metrics

GitLab 13.8 released with a Pipeline Editor, DORA metrics, quality of life improvements, and much more!

Today, we are excited to introduce a dedicated Pipeline Editor, a deployment frequency dashboard, and several quality of life improvements that will make using GitLab every day even more enjoyable. These are just a few highlights from the 50+ improvements in this release.

The new Pipeline Editor makes CI/CD easy to use

Since its inception, the defining feature of GitLab CI/CD has been the .gitlab-ci.yml configuration file. Configuring pipelines as code means you can version control and collaborate on pipelines using the same interfaces you use for your application code. Additionally, GitLab's advanced syntax provides a high degree of customization for sophisticated and demanding CI/CD use cases. However, all of this power and flexibility comes with a fair bit of complexity. This is why our vision for CI/CD is to create a visual pipeline authoring experience, built-in to GitLab, that simplifies the complexity letting you quickly create and edit pipelines while still exposing advanced options when you need them.

Today, we’re pleased to introduce the first iteration of the Pipeline Editor. Starting in 13.8, you'll have a dedicated editor designed for CI/CD with some enhanced functionality such as built-in linting and configuration validation. A pipeline visualizer in the editor will show you what your pipelines will look like before you commit your changes. These capabilities allow new users to get started with GitLab CI/CD quickly and make experienced power users more efficient. This is just the beginning of what's in store for the Pipeline Editor. We can't wait for you to try it out so you can share your feedback, suggestions, and code contributions.

Improve your DevOps maturity with deployment frequency metrics

IT leaders and practitioners alike love DevOps. Developers and software engineers love that DevOps makes their job easier while IT leaders love that DevOps makes the business perform better. For several years, DORA, the DevOps Research and Assessment firm, has conducted primary research on the impact of DevOps in the enterprise. Their published results have shown that DevOps maturity leads to positive business outcomes like happier customers, greater market share, and increased revenue. Four metrics in particular, commonly known as the “DORA 4”, are highly correlated with business performance. These are deployment frequency, lead time for changes, time to restore service, and change failure rate.

We’ve heard from many of you that you want to measure these metrics so that you can improve them. However, instrumenting your systems to capture and report on these metrics can be difficult and time-consuming. We decided to build them into GitLab for you so you can focus on improving your DevOps maturity instead of instrumentation. Starting with GitLab 13.8 you can find deployment frequency charts in your CI/CD analytics. This is just the first of the DORA 4 metrics to come to GitLab. Our vision for the coming year will be to add the additional three metrics so you’ll be able to measure and optimize your DevOps practices.

A few small features to improve your quality of life

As GitLab gets better with every iteration sometimes the most exciting improvements aren’t the big new features, but the small UX improvements that take a tedious task and make it simple and easy. In this release, we’ve shipped several long-asked-for enhancements that we think you’ll enjoy such as the ability to:

And much more!

These are just a few of many ways GitLab has been made better in this release. Read on to see more. And, if you'd like to preview what's coming in next month’s release, check out our Upcoming Releases page as well as our 13.9 release kick-off video.

Join us for an upcoming event

GitLab MVP badge

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

Yogi has been an outstanding frontend community contributor and in GitLab’s recent hackathon, submitted over 30+ merge requests that helped fix long-standing bugs, align our UX and help our platform consistency. That is A LOT of MRs in an area we are working hard to make as many improvements as possible for our users!

Yogi is a fantastic great example of how community members can embrace and champion our values at GitLab through transparency, iteration, and collaboration. Thank you Yogi, we appreciate you!

13.8 Key improvements released in GitLab 13.8

Pipeline editor

Pipeline editor

GitLab CI/CD provides you with flexible options to support a variety of advanced pipeline use cases. Pipeline syntax can be verbose and sometimes complicated, especially for those who are new to GitLab CI/CD. In this release, we are proud to introduce our first iteration of the Pipeline Editor.

The editor makes the CI configuration authoring experience much easier for both novice and advanced users alike. The pipeline editor is a single solution that groups all the existing CI authoring features (and future ones) in a single location. The pipeline editor is the best place to go when configuring your pipeline.

In addition to the editing experience, it has additional features that help you author pipelines without extra manual steps. CI validation continuously checks your pipeline configuration and provides you with an indicator that your pipeline configuration is valid. The new Pipeline Visualizer provides you with a graphic representation of your pipeline configuration. The Lint tab validates your pipeline syntax and provides you with details about each job.

CI lint tool in the pipeline editor page

CI lint tool in the pipeline editor page

The CI lint tool validates your pipeline syntax and provides you with some details about each job. Previously, CI lint was located on the jobs page which was difficult to find and access. In this release, accessing this tool is much easier than before because it is now included as a part of the new Pipeline Editor. With this improvement, you can easily use CI lint while editing your configuration and quickly validate that your syntax is what you want before committing the changes.

CI lint tool in the pipeline editor page

CI/CD configuration validation in Pipeline Editor

CI/CD configuration validation in Pipeline Editor

Previously, to validate your CI/CD configuration, you had to navigate to the CI lint page or commit your changes and look for any errors. In this release, we’ve added verification in the pipeline editor itself. It continuously checks your pipeline configuration before writing your .gitlab-ci.yml file and provides you with an indicator that your configuration is valid. This saves you time and effort that could otherwise be spent optimizing your pipeline.

CI/CD configuration validation in Pipeline Editor

Visualization of pipeline configuration

Visualization of pipeline configuration

A complex CI configuration can be difficult to understand as a developer, especially when trying to predict how your pipeline might behave (or misbehave). Without a visual aid, it is challenging to form a mental image of the relationships between all of the jobs and determine how they are interconnected. In our first iteration of a pipeline visualization, you can now see a graphic representation of your .gitlab-ci.yml configuration to better understand and predict how your pipelines will perform.

Visualization of pipeline configuration

Deployment frequency charts

Deployment frequency charts

Knowing and monitoring deployment frequency is a starting point for organizations adopting DevOps. We are proud to introduce deployment frequency charts at the project level so that you and your development teams can monitor the efficiency of deployments over time, find bottlenecks, and make improvements when necessary. This is the first of the DORA metrics that we are making available within GitLab out of the box.

Deployment frequency charts

Send an email to an issue

Send an email to an issue

To more efficiently integrate GitLab into your email workflows, each issue now has a unique email address. Emailing an issue creates a new comment on your behalf. You can now say goodbye to manually copying email content and attachments into your GitLab issues.

Send an email to an issue

Click and drag multiline merge request comments

Click and drag multiline merge request comments

Commenting on a single line is great for simple kinds of code review feedback, but often a comment addresses multiple lines in the diff. For instance, a portion of a logic block, a paragraph of prose, or an entire function. This forces users to choose a single line to provide feedback, but the feedback refers to other portions of the file.

Previously, users could select multiple lines after posting a comment by adjusting line numbers up and down from the original comment point. Now, users can click at the beginning of a line and drag the comment marker across multiple lines to highlight and reference multiple lines when leaving feedback in a merge request.

Download artifacts directly from the merge request widget

Download artifacts directly from the merge request widget

In this release, we added the ability to download build artifacts directly from the MR widget. This is especially useful for mobile development. An example of this is where users want to test an Android package of a specific build created on a physical device or an emulator. You can now access these artifacts directly from the merge request widget without having to find the artifacts buried in the pipeline view.

Download artifacts directly from the merge request widget

Repeat failed test counter

Repeat failed test counter

When you’re reviewing the results of a Merge Request’s pipeline execution, there may be test failures to investigate further. It’s often hard to validate whether a test failure is accurate and needs to be fixed, or if it’s simply a flaky test that can be ignored. Figuring this out can be even more difficult when you’re not dealing with a brand new test failure.

The first minimal viable change for the repeat failed test counter will provide you a count of how often a test has failed in previous pipelines on the Test Summary Merge Request Widget. We are requesting feedback from the wider community in this issue to understand what we can improve in future iterations of this feature.

Repeat failed test counter

Deploy Boards are available in Core

Deploy Boards are available in Core

Deploy Boards offer a consolidated view of the current health and status of each CI environment running on Kubernetes, displaying the status of the pods in the deployment. Developers and other teammates can view the progress and status of a rollout, pod by pod, in the workflow they already use without any need to access Kubernetes.

Earlier this year GitLab committed to moving 18 features to our open source core product. With this release of GitLab we’ve completed the work to move Deploy Boards to Core. We’re excited about bringing these features to more users and seeing what use cases and workflows you’re able to use them for.

Deploy Boards are available in Core

Rebase quick action for merge requests

Rebase quick action for merge requests

Rebase is a Git command used to reapply commits on top of a new commit. In practice, this means reapplying commits from a feature branch on top of the latest version of the target branch (e.g. main). In this way, it is possible to bring the feature branch up to date and resolve any conflicts without using a merge commit resulting in a simpler linear Git history.

GitLab 13.8 brings the ability to execute the rebase quick action in merge requests, allowing you to quickly invoke the rebase Git utility.

On a merge request comment, type /rebase and click the Comment button. It’s that simple.

Rebase quick action for merge requests

Distributed Reads for Gitaly Cluster

Distributed Reads for Gitaly Cluster

Users want the highest possible levels of fault tolerance in highly-available Gitaly Clusters. This release introduces distributed reads for Gitaly Clusters. Instead of always reading from the primary node, Gitaly now automatically distributes read requests to any up-to-date node in the cluster. Distributing requests maximizes both performance and value proposition by giving your users access to all the computing resources provisioned in the cluster. Users also want to prevent performance degradation from noisy-neighbor repositories on the same node. This issue is particularly important for large and busy monorepos, where thousands of engineers and CI pipelines simultaneously access the same Git repository. By horizontally distributing read requests, Gitaly Clusters improve performance across all repositories in the cluster. To read more about Gitaly Clusters and how we’ve developed our own traffic management solution for Gitaly Cluster, see our blog post, Meet Praefect: The traffic manager making your Git data highly available.

Distributed Reads for Gitaly Cluster

GitLab Pages is now available for Kubernetes deployments of GitLab

GitLab Pages is now available for Kubernetes deployments of GitLab

GitLab Pages is a popular static-site hosting service built into GitLab, and we are excited to announce that it is now available for GitLab instances running on Kubernetes. Pages was one of the last remaining feature gaps compared to an Omnibus deployment.

Custom domains are supported today, however, access control will arrive in a future release.

GitLab Pages is now available for Kubernetes deployments of GitLab

Scope a board to the current iteration

Scope a board to the current iteration

Many teams use boards to manage issues during an iteration. In 13.6, we added support for filtering issues on a board to a specific Iteration, but it is cumbersome to remember to apply that filter every time you go to your board.

In this release, we’ve added the ability to scope your board to the currently active iteration.

Scope a board to the current iteration

13.8 Other improvements in GitLab 13.8

Allow GitLab.com group owners to bypass SSO enforcement

Allow GitLab.com group owners to bypass SSO enforcement

In GitLab 13.8, we will allow group owners to bypass SSO enforcement to access to their owned top-level groups. This will allow group owners to modify SAML SSO settings and prevent group member lockout due to SAML SSO misconfiguration or changes in identity providers.

Group webhook for members (edit, remove)

Group webhook for members (edit, remove)

In GitLab 13.7, we introduced a webhook that is triggered when a new member is added to a group. In GitLab 13.8, the group member events webhook will also be triggered if the access level of a user has changed, the expiration date for user access has been updated, or a user has been removed from the group. With the addition of these events, the group member events webhook can be used to be aware of all changes made to group members without relying on API calls which put unnecessary performance load on your GitLab instance.

Support for predefined variables in CI include section

Support for predefined variables in CI include section

Regulated customers rely on GitLab’s CI/CD capabilities to define and automate their security and compliance jobs and processes for deploying changes to sensitive environments. They need to ensure they’re maintaining separation of duties between the teams writing code and the teams deploying that code and these jobs always run in sensitive environments.

In 13.8, you can now use predefined project variables in the include: section of your .gitlab-ci.yml file. This change is part of a bigger solution to bring better separation of duties control to your GitLab CI/CD pipelines.

Display all available quick actions in autocomplete

Display all available quick actions in autocomplete

When you enter / into a description or comment field, all available Quick Actions are now displayed in a scrollable list. Quick Actions are a great way to efficiently update data on an issue, merge request, or epic, and this small improvement helps them be more discoverable in the context in which they are used.

Display all available quick actions in autocomplete

Group issues by label in the iteration report

Group issues by label in the iteration report

You can now group issues in an iteration report by labels. This provides teams with a way to view progress during an iteration segmented by the many dimensions that labels are often used to represent.

Group issues by label in the iteration report

Disable Operations features on a project

Disable Operations features on a project

GitLab offers a variety of tools to help you monitor and operate your applications, but not all projects in GitLab are web applications. For example, if you are working on an NPM package, hosting configuration files, or using a Wiki-only project, you might find that the Operations features are not needed by your project.

In GitLab 13.8, you can now disable the Operations features on a project-by-project basis, which removes access to the features and hides the menu item from the left sidebar. The new configuration can be found in Settings > General under the Visibility, project features, permissions section. Configuring your project in this way ensures that only the features that you use and that your project supports are available and visible in the GitLab interface.

Optional sections for code owners

Optional sections for code owners

Code owner sections allow multiple teams to configure their own code owners independently in the same file. This helps when multiple teams are responsible for common parts of the code, by helping authors getting feedback from the right reviewers. However, when approval from Code Owners is required, this applies to all the sections meaning all teams need to approve, which can hold back changes from getting merged.

GitLab 13.8 introduces the ability to designate optional sections in your CODEOWNERS file. Simply prepend the section name with the caret ^ character and the section will be treated as optional. This means, related changes through merge requests will not require approval from designated owners. With optional sections, you may continue to designate responsible parties for various parts of the code while providing a more relaxed policy for parts of your project that may be updated often but don’t require stringent reviews.

Rate limit dry run mode and bypass mechanism

Rate limit dry run mode and bypass mechanism

It can be challenging to set rate limits for your application in such a way to allow requests from trusted sources while blocking malicious traffic. We have made several enhancements to make it easier to properly set rate limits. First, you can now test rate limit settings using a new dry run mode that checks requests against each rate limit and logs the results without actually blocking the client. This lets you fine-tune request throttle settings before enabling them in production.

Second, you can also configure specific requests. This allows you to better support trusted services.

Finally, you can configure specific users to bypass the rate limiter. This allows you to better support trusted users accessing your GitLab instance.

Configure multiple image pull policies for Docker executor

Configure multiple image pull policies for Docker executor

When your CI jobs are retrieving a container image from a container registry, a lost network connection can result in hours of lost development time and can negatively impact time-sensitive product deployments. To address this resiliency problem, the GitLab Runner Docker executor now supports the use of multiple values for the pull_policy configuration, which is defined in the GitLab Runner config.toml file. You can use these values, or stacked image pull policies, to configure combinations of pull policies and mitigate the impact caused by lost connectivity. For example, if you configure pull_policy =["always", "if-not-present"], the pull policy will always pull the image. However, if the target container registry is not available, the GitLab Runner Docker executor will fall back and use the if-not-present policy, which means a local copy of the image will be used for that pipeline job.

Configure multiple image pull policies for Docker executor

GitLab Runner 13.8

GitLab Runner 13.8

We’re also releasing GitLab Runner 13.8 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:

Runner bug fixes:

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

Support variables for pipeline rules

Support variables for pipeline rules

Previously, the rules keyword was limited in scope and only determined if a job should be included or excluded from pipelines. In this release, you can now decide if certain conditions are met and subsequently override variables in jobs, providing you with more flexibility when configuring your pipelines.

Support variables for pipeline rules

Install NuGet packages from your group or subgroup

Install NuGet packages from your group or subgroup

You can use your project’s Package Registry to publish and install NuGet packages. You simply add your project as a source using the NuGet CLI, Visual Studio, or the .NET CLI. For example, using the NuGet CLI you can run:

nuget source Add -Name <source_name> -Source "https://gitlab.example.com /api/v4/projects/<your_project_id>/packages/nuget/index.json" -UserName <gitlab_username or deploy_token_username> -Password <gitlab_personal_access_token or deploy_token>

This works great if you have a small number of projects. But if you have multiple projects nested within a group, you might quickly find yourself adding dozens or even hundreds of different sources. For large organizations with many teams, it’s common for a team to publish packages to their project’s Package Registry alongside the source code and pipelines. But, they also need to be able to easily install dependencies from other projects within their organization.

Moving forward, you can install packages from your group so you don’t have to remember which package lives in which project. Simply add your group as a source for NuGet packages and you can install any of the group’s packages.

nuget source Add -Name <source_name> -Source "https://gitlab.example.com /api/v4/groups/<your_group_id>/-/packages/nuget/index.json" -UserName <gitlab_username or deploy_token_username> -Password <gitlab_personal_access_token or deploy_token>

We hope this feature makes sharing dependencies between projects a little bit easier.

Improved pipeline status email subject line

Improved pipeline status email subject line

GitLab sends email notifications when your pipeline succeeds, fails, or is fixed. In previous releases, these emails looked similar. This made it hard to tell the pipeline status without reading the entire body of the email. This release updates the subject line of these email notifications so you can determine pipeline status with a quick glance.

Improved pipeline status email subject line

Upload metrics images directly to incidents

Upload metrics images directly to incidents

Processing incidents during a fire-fight requires responders to coordinate across multiple tools to evaluate different data sources. Collecting and assessing metrics, logs, and traces - and sharing these with a response team - is time-consuming and challenging. We’ve streamlined this workflow by providing drag-and-drop uploads for these screenshots in a new Metrics tab on incidents. Aggregate and centrally locate all your screenshots of metrics so your team can quickly access and reference important charts.

Upload metrics images directly to incidents

Geo support for PostgreSQL high-availability in Alpha

Geo support for PostgreSQL high-availability in Alpha

Patroni is a solution for PostgreSQL high availability which also allows the configuration of a highly available PostgreSQL standby cluster on a Geo secondary. This configuration is important when a secondary is used as part of a disaster recovery strategy because it allows systems administrators to mirror the number of database nodes on the primary and secondary. This means that after a failover, no additional database nodes need to be provisioned to regain high-availability.

Geo now provides alpha-level support for highly available PostgreSQL configurations using Patroni. We’ve upgraded Patroni to 2.0.1, added failover documentation, and fixed a number of bugs.

Omnibus improvements

Omnibus improvements

Advanced Search can scale from small personal instances all the way up to GitLab.com. On some of the largest instances, however, search can slow down as the size of the index grows, and the number of permissions needing to be checked.

In GitLab 13.8 we have split out issues into their own index, making Advanced Search faster for larger instances. We have also simplified the method of permissions checks, further improving performance.

This update will apply automatically, without a need to conduct a manual reindex. The process takes less than 2 hours, however, there will be a delay in indexing new content while this completes.

API Fuzz Testing results now visible in Security Dashboard

API Fuzz Testing results now visible in Security Dashboard

API fuzz testing results are now shown in the Security Dashboard and all other locations that security scanners show their results. You can now triage API fuzz testing results, create issues for them, and engage with your teams just like you can with other scanners.

We’re incredibly excited to bring these results out of the Tests tab so that you can integrate API fuzz testing alongside other security scanners and truly shift security left.

API Fuzz Testing results now visible in Security Dashboard

Add DAST.latest.gitlab-ci.yml template

Add DAST.latest.gitlab-ci.yml template

GitLab’s DAST has always had only a single template that isn’t versioned and is updated whenever we need to change things. This has proven difficult for users whose tests break after a template update. Starting in GitLab 13.8, we introduce a .latest version of the template. This template includes all template changes made between major releases, including breaking changes. This gives users a warning that changes are coming and enables them to test the changes for themselves before being forced to switch.

Breaking changes are brought into the stable template on the next major GitLab version. For non-breaking changes, these can be brought into the stable template after living in the latest template for a few releases. The speed at which the changes are incorporated into the stable template depends on a number of factors and takes into account feedback from users as they test the changes in the latest template.

Improved SAST severity data for JavaScript vulnerabilities

Improved SAST severity data for JavaScript vulnerabilities

When available from our security scan analyzers, GitLab Static Application Security Testing provides severity data for identified vulnerabilities. We recently updated our JavaScript analyzer, ESLint, to add support for severity and CWE data. This data will help increase the usability and accuracy of Security Approval Rules as fewer vulnerabilities will report ‘Unknown’ severity. Additionally, this data is shown on vulnerability detail pages providing more information and links to relevant information about vulnerabilities making it easier for developers to understand and remediate issues. In the future, we will augment other analyzers missing vulnerability metadata and add a mechanism to allow customized vulnerability metadata enabling organizations to tailor results to match their risk profiles.

Improved SAST severity data for JavaScript vulnerabilities

Site validation for on-demand scans

Site validation for on-demand scans

Beginning in GitLab 13.8, users can validate that they own or have permission to test the domains added as a site profile. By adding a text file with a project- and site-specific string to their site, users can validate ownership of the domains. The validation process unlocks the ability to run active DAST scans against the domain. Since active DAST scans include actual attacks against the site, site validation provides a level of assurance that users can’t accidentally run an active scan against a site where they could cause data loss or damage. Because of this, any site profile that uses a domain that isn’t validated is only allowed to use scanner profiles that use a passive scanning mode.

Busy status indicator

Busy status indicator

With status updates, users can currently share a personalized status message and emoji with their team. We are now taking this one step further with a busy indicator. By marking yourself as Busy, your coworkers can easily see when you are unavailable for code reviews and other tasks. The Busy status will be displayed next to your name throughout the GitLab user interface.

Busy status indicator

Migrate Groups directly between instances

Migrate Groups directly between instances

A faster and easier way to migrate your GitLab Groups is on the way. Group Migration is a new feature that lets you copy a GitLab Group from one instance to another directly, without having to export and import any files. In this release, we migrate only the Group object with basic fields. We plan to follow up with more and more fields and related objects until all relevant data in a Group is migrated in this easy-to-use fashion.

Welcome email for SAML and SCIM provisioned accounts

Welcome email for SAML and SCIM provisioned accounts

In GitLab 13.8, users created via SCIM or SAML will receive a welcome email that informs them that their account was created for use within their organization’s group. Future iterations will give group administrators more control over accounts that are provisioned by their SAML or SCIM integrations.

Export requirements to a CSV file

Export requirements to a CSV file

After completing development and verifying your product meets all requirements, it may be necessary to export the requirement status to allow for incorporation into a higher level requirements traceability analysis. With the introduction of the requirements export feature, this is now possible! Simply initiate the requirement export and they will be automatically sent to you in .CSV format, ready to import into other tools or provide to your customer.

This is the first iteration of this feature, so please provide feedback and follow along in the Requirements Export Epic.

Export requirements to a CSV file

Approval Rule information for Reviewers

Approval Rule information for Reviewers

When working to have your merge request reviewed, approved, and finally merged, it’s important to select the right people to perform those tasks. Asking for a review from people who can’t provide the approvals can slow down the process of delivering your contribution.

From GitLab 13.8 onwards, when selecting a reviewer for your merge request, you can see which approval rules that the user matches displayed right below the reviewer’s name.

Approval Rule information for Reviewers

When viewing a commit in GitLab, the merge requests containing the commit are linked. Finding the merge request that added the commit is very useful when you are trying to find the business and technical context of a change.

If you use squash or merge commits, merge request information was not previously included. GitLab 13.8 now includes merge request links for all commit types, ensuring you can find where a change was introduced.

Quickly edit Wiki’s sidebar

Quickly edit Wiki’s sidebar

Creating a Markdown file named _sidebar in the Wiki will use the contents of that file to generate a custom sidebar navigation menu for your project. Editing this file, however, was tricky as there was nowhere in the interface to open _sidebar again.

Thanks to a wonderful community contribution from GitLab user Frank Li, starting in GitLab 13.8 there is now an Edit sidebar button in the top right of the Wiki page. Clicking this button will automatically create the _sidebar file if it doesn’t already exist and open it in the page editor. With this quick access, it is more intuitive to create and easier to maintain your custom Wiki navigation.

Use rich output for Jupyter notebooks

Use rich output for Jupyter notebooks

Jupyter notebooks are documents that contain live code, equations, visualizations, and narrative text. They are widely used for data cleaning and transformation, numerical simulation, statistical modeling, data visualization, machine learning, and more. They are capable of using “rich output” to show an object’s rendered representation, such as HTML, JPEG, SVG, or LaTeX files. Previously, opening the notebook in Jupyter was the only way to read it with rich output.

GitLab 13.8 now shows rich output for Jupyter notebook content by default. This is an excellent way both to preview changes to your files as well as consume Jupyter notebook without ever having to leave GitLab.

Use rich output for Jupyter notebooks

Control job status using exit codes

Control job status using exit codes

You can use the allow_failure keyword to prevent failed jobs from causing an entire pipeline to fail. Previously, allow_failure only accepted boolean values of true or false but we’ve made improvements in this release, so now you can use the allow_failure keyword to look for specific script exit codes. This gives you more flexibility and control over your pipelines, preventing failures based on the exit codes.

Control job status using exit codes

Project configuration to control storage of latest artifacts

Project configuration to control storage of latest artifacts

Keeping the latest artifact from the most recent successful job is a useful default behavior but can also result in significant amounts of storage usage. This can cause an unexpected surge in disk space usage if you have pipelines that generate large artifacts. To improve storage consumption management, you can now disable this behavior for any project in the settings.

Coming up next, gitlab#276583 will allow you to entirely disable keeping the latest artifacts at the instance level.

Project configuration to control storage of latest artifacts

Use both branch and MR pipelines without duplication

Use both branch and MR pipelines without duplication

Previously it was not possible to run pipelines for branches first, then switch to merge requests pipelines when the MR is created. Consequently, with some configurations, a push to a branch could result in duplicate pipelines if a merge request was already open on the branch: one pipeline on the branch and another for the merge request. Now you can use the new $CI_OPEN_MERGE_REQUESTS predefined environment variable in your CI configurations to switch from branch pipelines to MR pipelines at the right time, and prevent redundant pipelines.

Use both branch and MR pipelines without duplication

GitLab Terraform Provider 3.4 updates

GitLab Terraform Provider 3.4 updates

If you use Terraform to set up GitLab, we are happy to announce version 3.4.0 of the GitLab Terraform Provider. In the past months, the provider received support of project mirroring, group sharing, project approval rules, and instance-level CI variables, besides many smaller enhancements and a few bug fixes.

Manage Terraform state files through the UI

Manage Terraform state files through the UI

When managing your infrastructure with Terraform, you might create multiple state files, such as state files for each branch. To debug issues, you need an overview of the state files attached to your project, and various actions you can take for each state file. In previous versions of GitLab, managing Terraform state files required the API for tasks like releasing a state lock. We are now introducing a UI to list existing state files. It enables project maintainers to lock or unlock a state file, remove the state JSON, or to remove a state file entirely.

Manage Terraform state files through the UI

Compare repositories and validate if they are the same

Compare repositories and validate if they are the same

One Git repository can be compared to another by checksumming all refs of each repository. If both repositories have the same refs, and if both repositories pass an integrity check, then we can be confident that both repositories are the same. For example, this can be used to compare a backup of a repository against the source repository.

The new gitlab:git:checksum_projects rake task allows systems administrators to select a subset of projects by ID or loop through all projects, and output a checksum of the Git references that can be compared to a copy of the same project.

GitLab chart improvements

GitLab chart improvements

In GitLab 13.8, we added the ability to specify multiple virtual storages within our Praefect chart. If you have enabled Praefect, which is off by default and not yet GA, please note that the StatefulSet name for Gitaly will now include the virtual storage name. Because of this name change, any existing Praefect-managed Gitaly StatefulSet names (and, therefore, their associated PersistentVolumeClaims) will change as well, leading to repository data appearing to be lost. In this case, repository data can be restored by following the managing persistent volumes documentation, which provides guidance on reconnecting existing PersistentVolumeClaims to previous PersistentVolumes.

Single-node instances will now upgrade to PostgreSQL 12 by default

Single-node instances will now upgrade to PostgreSQL 12 by default

In GitLab 14.0, we plan to require PostgreSQL 12. PostgreSQL 12 offers significant indexing and partitioning benefits, along with broader performance improvements.

To prepare, single-node instances using the Omnibus-packaged version of Postgres will now automatically upgrade to version 12 by default. If you prefer, you can opt-out of automatic upgrades.

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

Searching for a file is the top use case in Advanced Search. Before this release, searching for files often required some specific syntax and was not very intuitive.

With GitLab 13.8, Advanced Search now supports full path searching. We have also made the file syntax search more flexible.

Improved file searching in Advanced Search

Active scan mode in on-demand DAST scanner profile

Active scan mode in on-demand DAST scanner profile

Used in conjunction with the new site validation feature, active DAST scans are now available for configuration in the on-demand DAST scanner profile. After validating a site for ownership, you can configure an active scan to run against the site. These scans include actual, destructive, malicious attacks against the site. Because of this, we recommend and encourage that you only use an active scan on staging and test sites that do not contain production data, where data loss is not a concern.

Performance improvements

Performance improvements

In every release, we continue to make great strides in 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.8, we’re shipping performance improvements for issues, projects, milestones, and much more! Some improvements in GitLab 13.8 are:

Deprecations Deprecations

DAST environment variable renaming and removal

DAST environment variable renaming and removal

GitLab 13.8 renames multiple environment 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 will now be 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

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: January 22nd, 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: January 22nd, 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: January 22nd, 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: January 22nd, 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: January 22nd, 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: January 22nd, 2021

Deprecate Gitaly support for TLS 1.0 and 1.1

Deprecate Gitaly support for TLS 1.0 and 1.1

Support for TLS 1.0 and TLS 1.1 has been deprecated and removed from GitLab for security reasons. We will do the same for Gitaly as there are cases where the minimum TLS version was not set and was therefore defaulted to TLS 1.0.

Gitaly will be configured to use TLS 1.2 at a minimum for all client and server-side connections.

Planned removal date: January 22, 2021

Deprecate pulls that use v1 of the Docker registry API

Deprecate pulls that use v1 of the Docker registry API

GitLab is disabling pulls via the Docker registry v1 APIs on January 22nd, 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:

  1. Update your Docker Engine to 17.12 or later so it is compatible with the v2 registry API.
  2. 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: January 22nd, 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. Git version 2.31.0 (scheduled for release March 15th, 2021) 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.

For more information, see the related epic and the Git mailing list discussion.

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

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

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. In 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: Jun 22, 2021

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

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

We have enabled a deeper integration with Opsgenie and other alerting tools through HTTP endpoint integrations so you can see alerts within the GitLab interface. As a result, the previous link to Opsgenie in the alerts list has been deprecated in this release.

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