Dec 22, 2020 - Michael Karampalas

GitLab 13.7 Release

GitLab 13.7 released with merge request reviewers and automatic rollback upon failure

GitLab 13.7 released with merge request reviewers, automatic rollback in case of failure, quick action to clone issues, GitLab Runner container on OpenShift, and much more!

What a year 2020 has been! We're excited to share what's new in 13.7 with over 45 features and improvements shipping just in time for the holidays!

On behalf of everyone at GitLab, I want to take a second to thank everyone in our community for your contributions and the positive impact you've made. Without you, GitLab would not be what it is today.

Here's to you and all of our team members that helped make 2020 an incredible year despite the adversity and unprecedented times. Please continue staying safe, happy, and healthy this holiday season.

Here's what you can look forward to in 13.7:

Enhanced project management for cross-collaboration

Merge Requests (MRs) are crucial to foster cross-collaboration and can be directly linked to relevant issues, providing a central location to communicate via comments, suggest code changes, perform code reviews, and much more. In this release, we've added merge request reviewers, a capability to improve the code review process by making reviews easier and more organized. Now you'll be able to quickly find out who's involved in the merge request or request a formal review that will send them a notification.

Context switching and manual tasks in your workflow hinder your ability to efficiently collaborate across groups and projects. It means you spend less time developing valuable features and more time managing your projects, which is why the ability to clone issues with quick actions is so valuable for you to streamline agile planning and project management.

Collaborating on projects and iterating rapidly to develop your applications means you need to be able to quickly determine the order of importance of your issues, identify any blockers, and use that information to prioritize what you'll work on next. Now, you can sort issues by blockers to quickly find out which of your issues are blocking progress for other issues, as well as easily sort by the number of blockers in your issue list.

Improved release automation and deployment flexibility

You need flexibility to control how you orchestrate, automate, and deploy your applications on a regular basis. Deploying your applications reliably and frequently gets value into the hands of your customers sooner.

To improve how GitLab automates releases, we've added automatic rollback in case of failure. This feature automatically reverts an unsuccessful deployment back to the last successful deployment and sends an automatic notification to alert you of the status. You won't have to manually make any changes and can be confident that potential problems won't cause downtime or intensify while you work towards a fix.

An improvement that goes well with automatic rollback in the event of a failure is the ability to see the deployment status in the Environment page. Now you can easily find deployment statuses and identify what actions you need to take, such as stopping or rolling back a deployment.

We've also shipped the first officially supported beta of GitLab Runner container on Red Hat OpenShift and our Certified Runner Operator to give you more flexibility over how you release with GitLab. We're working to make this generally available soon, so stay tuned for more information in future releases.

More reliable and efficient package and dependency management

Your workflow depends on a wide variety of programming languages, binaries, integrations, and artifacts that are all important inputs or outputs as a result of your development process. The more efficiently you can manage your packages and dependencies, the less development time goes to waste, and with efficiency in mind, we've added the option to quickly find and view generic packages.

We've also made improvements to GitLab's Dependency Proxy, which, by the way, was made available in Core in GitLab 13.6.

You can now avoid Docker rate-limits and speed up your pipelines with the Dependency Proxy to assure confidence in reliability and improve efficiency when caching your container images hosted on DockerHub.

Another improvement that many of you in the community were anticipating, the Dependency Proxy now works with private projects and addresses the limitations that prevented those of you with private projects from taking advantage of this feature.

Last but not least, you'll be able to use pre-defined variables with the Dependency Proxy instead of relying on your own defined variables or hard-coding values in your gitlab.ci-yml file. This provides a more scalable and efficient way to get started proxying and caching images.

And more

Check out a few other awesome features shipping in 13.7 below:

Import requirements from a CSV file
SAML user provisioning
Set deployment traffic weight via UI
API support for Deployment Frequency

These are just a few highlights out of many new features and performance improvements. 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.8 release kick off video.

GitLab 13.7 released with merge request reviewers and automatic rollback upon failure Click to tweet!

Join us for the GitLab Hackathon on January 6th - 7th, 2021

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

Rachel has been actively helping the Technical Writing team enforce consistent writing style to fix the use of future tense in our docs. In 13.7, Rachel opened 33 MRs, helping the team chip away at an important and laborious task. Thank you Rachel! 🙌

13.7 Key improvements released in GitLab 13.7

Reviewers for Merge Requests

Reviewers for Merge Requests

SaaS

Self-Managed

Asking a colleague to review your code should be a routine part of contributing code, but it’s often needlessly complex. A simple task like asking for a review can lead to confusion. For example, how should you ask? An email? Comment? Chat message? Without a formal process, reviews can be inconsistent and hard to keep track of. Previously, an option was to assign a reviewer to a merge request, but even with this formality, both the author and the reviewer appeared in the same assignee field, making it hard for other team members to know who was doing what.

GitLab 13.7 introduces reviewers for merge requests, which allows authors to request a review from someone. The new “Reviewers” field allows users to be designated as reviewers in a similar way to assignees. The reviewers receive a notification inviting them to review the merge request. This provides a formal process for requesting a review and clarifies the roles of each user in a merge request.

Future iterations will include showing the most relevant reviewers for a merge request as well as a streamlined merge request approval flow that puts reviewers at the center. You can follow along in the merge request reviewer assignment epic for more details.

Documentation Issue

Auto rollback in case of failure

Auto rollback in case of failure

SaaS

Self-Managed

If you have a critical problem with a deployment, manual actions to fix it often take too long and lead to a degradation in production that impacts your users. Now, you can leverage an automatic rollback mechanism that reverts your deployment back to the last successful deployment. Also, when GitLab finds problems in production it automatically notifies you with an alert. This gives you peace of mind and precious development time to debug, investigate, and fix problems without causing downtime.

Documentation Issue

Clone an issue with a quick action

Clone an issue with a quick action

SaaS

Self-Managed

To make generating similar issues more efficient, issues now support a /clone quick action, which creates a new issue in the same project, with an identical title, description, and metadata. The /clone quick action replaces a more cumbersome process, which involves multiple steps to create an issue, copy the ID or path of the source issue, and use the copy_meta quick action.

By default, issues are cloned into the same project and do not include system notes and comments, but you can also change the default behavior when cloning.

Documentation Issue

GitLab Runner for Red Hat OpenShift

GitLab Runner for Red Hat OpenShift

SaaS

Self-Managed

Available today is the GitLab Runner container image for the Red Hat OpenShift Container Platform. To install the runner on OpenShift, you can use the new GitLab Runner Operator available from the beta channel in Red Hat’s Operator Hub - a web console for OpenShift cluster administrators to discover and select Operators to install on their cluster. Operator Hub is deployed by default in the OpenShift Container Platform. We plan to transition the GitLab Runner Operator to the stable channel, and by extension GA, in early 2021. Finally, we are also developing an operator for GitLab, so stay tuned to future release posts for those announcements.

Documentation Issue

Show deployment status on the Environments page

Show deployment status on the Environments page

SaaS

Self-Managed

Previously, you had no way of knowing that a deployment is in progress when viewing the Environments page. With deployment status and alerts now visible, the Environments page gives you an indication of what action you can take based on the deployment status (successful, failed, or in progress). For example, you might want to stop a deployment that is currently in progress, or roll back a finished deployment.

Documentation Issue

Show deployment status on the Environments page

Set deployment traffic weight via the UI

Set deployment traffic weight via the UI

SaaS

Self-Managed

In GitLab 13.7, you can change the canary weights directly from the Deploy Boards in the UI. You can change canary weights directly from gitlab-ci.yml and the API, but doing so in the UI lets you see the deployment and scale the pods up or down directly from the Deploy Boards. This gives you greater control over manual or timed incremental rollouts, and allows you to better mitigate risks.

Documentation Issue

Set deployment traffic weight via the UI

API support for deployment frequency

API support for deployment frequency

SaaS

Self-Managed

As part of the first iteration towards supporting DORA4 metrics natively in GitLab, this release adds API support for deployment frequency on the project level. This enables you to monitor the efficiency of your deployments over time, find bottlenecks easily, and quickly take corrective action when necessary.

Documentation Issue

Support multiple manifest files in a project

Support multiple manifest files in a project

SaaS

Self-Managed

In previous GitLab versions, the GitLab Agent for Kubernetes required users to collect all Kubernetes resources into a single manifest file. In this version of GitLab, the Agent can now grab Kubernetes manifests recursively from specified directories in your project. Your platform engineers can use a single repository to manage different clusters from one place, and can describe large deployments with a single Agent.

Documentation Issue

Support multiple manifest files in a project

Import requirements from external tools

Import requirements from external tools

SaaS

Self-Managed

Having all of your requirements in one place is crucial for efficient collaboration, so we are thrilled to announce that you can now import requirements from a CSV (comma-separated value) file!

This feature will allow your whole team to collaborate on requirements from GitLab, but still allow you to interface with customers, suppliers, and external organizations with ease. Stay tuned for upcoming requirement export functionality.

Documentation Issue

Integrate alerting tools with multiple HTTP endpoints

Integrate alerting tools with multiple HTTP endpoints

SaaS

Self-Managed

Alert integrations are a critical part of your Incident management workflows, which is why it is important for you and your team to have granular control over the endpoints and authentication tokens. The last thing you want is to take down all of your alerting by resetting a single authentication token! Setting up a HTTP endpoint for each of your monitoring tools allows your team to separately manage each tool without impacting alerting from other tools.

Documentation Epic

Integrate alerting tools with multiple HTTP endpoints

SAML Group Sync for GitLab.com

SAML Group Sync for GitLab.com

SaaS

Self-Managed

In GitLab 13.7, you can map a group in your identity provider to a GitLab.com group using SAML. Group memberships will be updated when a user signs in to GitLab through their SAML provider. This new functionality decreases the need for manual group assignment, reducing the group assignment workload for GitLab administrators. SAML group sync also improves the group member onboarding experience by reducing the need for access requests to GitLab group administrators.

Documentation Issue

13.7 Other improvements in GitLab 13.7

Group webhooks for members MVC

Group webhooks for members MVC

SaaS

Self-Managed

GitLab has made it easier for you to build user management automation with a webhook that is triggered when a new member is added to a group. Before, you had to run REST calls to identify new group members, which put unnecessary performance load on your GitLab instance.

Documentation Issue

Improved group members list filtering and sorting

Improved group members list filtering and sorting

SaaS

Self-Managed

We are continuing to improve our group members list with a new filtering and sorting experience. This will allow group administrators to quickly find the member information they need. For example, sorting by “Last sign-in” can be used to find users who haven’t accessed GitLab recently and assist in license management activities.

Improved group members list filtering and sorting

Documentation Issue

SAML user provisioning for GitLab.com

SAML user provisioning for GitLab.com

SaaS

Self-Managed

Previously, users needed to complete a sign-up form as part of onboarding into a SAML-enabled group. In GitLab 13.7, we have introduced user provisioning for SAML-enabled groups. When a user signs in to a SAML-enabled group for the first time, a user account will be created for them automatically if there isn’t an existing user with the same email. SAML provisioning improves the onboarding experience for new users and ensures that newly created accounts contain the right information.

Documentation Issue

Use a custom email address with Service Desk

Use a custom email address with Service Desk

SaaS

Self-Managed

The email address for the GitLab Service Desk has been difficult to remember, and therefore difficult for your users to use. With the introduction of configurable email address, it’s now possible to choose an address suffix that makes sense for your business identity, and is easier for your users to remember. This is one more step GitLab is taking to enable you to provide top quality support to your users.

Documentation Issue

Distinguish between formatting changes and edits made from the Static Site Editor

Distinguish between formatting changes and edits made from the Static Site Editor

SaaS

Self-Managed

The Static Site Editor offers an intuitive and familiar WYSIWYG editing mode for Markdown content. To ensure consistently formatted Markdown output, the WYSIWYG editor automatically reformats the page content to match the styling conventions defined in the Markdown parser. This happens entirely in the background before you even start editing. These formatting changes, however, are committed at the same time as your content edits. If the page you are editing did not follow the same styling conventions, it can be difficult for reviewers of the resulting merge request to differentiate between your intentional changes and the automatic formatting.

Starting in GitLab 13.7, the Static Site Editor will automatically fix inconsistencies in the Markdown syntax and commit any necessary formatting changes to a new branch. Once you’re done editing, the Publish button creates a separate commit that contains only your changes. This can save time for your reviewers, who instead of having to sift through syntax changes, can focus on your content.

In the future, we plan to make the formatting preferences customizable and you can follow the related issue for updates.

Documentation Issue

GitLab Runner 13.7

GitLab Runner 13.7

SaaS

Self-Managed

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

What’s new:

Bug Fixes:

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

Documentation

Pre-filled variables when running pipelines manually

Pre-filled variables when running pipelines manually

SaaS

Self-Managed

Previously when you wanted to manually run a pipeline, you needed to know the relevant variables and then enter them on the “Run Pipeline” page. This can be tedious and error-prone if there are numerous key-value pairs to enter. Now, the Run Pipeline form will generate with pre-filled variables for your pipeline based on the variable definitions in your .gitlab-ci.yml file, making this process more efficient.

Pre-filled variables when running pipelines manually

Documentation Issue

Packages built with CI/CD always display build info

Packages built with CI/CD always display build info

SaaS

Self-Managed

If you’ve been publishing packages to the Package Registry, you might have noticed that packages built with GitLab CI/CD did not always display the commit and pipeline responsible for creating or updating your package. This might occur for a few reasons.

First, it’s possible that we didn’t support this functionality yet, as was the case with Composer and Conan. Second, an issue occurred for those of you who have been updating the same version of a package from different branches or commits. A package with the same version can be published from different branches and/or commits. However, until recently, the UI displayed only the first deployment and left out any updates. In addition, the details page displayed the branch that created the package, not the most recent commit. As a result, you had to try and find this information by viewing your commit history, which was not very efficient.

Moving forward, any package created or updated with GitLab CI/CD will display commit and pipeline info in the Packages user interface. To avoid performance or UX issues, only five updates of a package will be displayed. In milestone 13.8, we will create a design that helps you intuitively view all historical data. In the meantime, you can use the Packages API to view the entire build history of a given package.

Packages built with CI/CD always display build info

Documentation Issue

Use pre-defined variables with the Dependency Proxy

Use pre-defined variables with the Dependency Proxy

SaaS

Self-Managed

By proxying and caching container images from Docker Hub, the Dependency Proxy helps you to improve the performance of your pipelines. Even though the proxy is intended to be heavily used with CI/CD, to use the feature, you had to define your own variables or hard-code values in your gitlab.ci-yml file. This made it difficult to get started for individuals, and prevented it from being a scalable solution, especially for organizations with many different groups and projects.

Moving forward, you can use pre-defined environment variables as an intuitive way to use the Dependency Proxy. The following variables are supported:

CI_DEPENDENCY_PROXY_USER: a CI user for logging in to the Dependency Proxy.
CI_DEPENDENCY_PROXY_PASSWORD: a CI password for logging in to the Dependency Proxy.
CI_DEPENDENCY_PROXY_SERVER: the server for logging in to the Dependency Proxy.
CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX: the image prefix for pulling images through the Dependency Proxy.

Give it a try and let us know what you think!

Documentation Issue

Add support for Kubernetes versions 1.17, 1.18, 1.19

Add support for Kubernetes versions 1.17, 1.18, 1.19

SaaS

Self-Managed

GitLab support for more recent Kubernetes versions enables you to benefit from GitLab’s Kubernetes integrations, such as the GitLab Agent for Kubernetes, Auto DevOps, and - on more recent clusters - GitLab Managed Apps. GitLab has added official support for Kubernetes versions 1.17, 1.18, and 1.19.

Documentation Issue

See which commits and pipelines run in the fork project vs. the parent project

See which commits and pipelines run in the fork project vs. the parent project

SaaS

Self-Managed

After we implemented issue #217451 in GitLab 13.3, you gained the ability to allow a parent project’s developers to create pipelines for merge requests in forked projects. However, there was no way to know the context in which the pipeline ran.

In this release, you can now see which commits and pipelines ran in the forked project vs. the parent project. Forked commits have a unique badge and a tooltip that lets you know they ran from a forked merge request. This makes it simple to understand the context in which your pipeline ran and eliminates the need to investigate the origin in more detail.

See which commits and pipelines run in the fork project vs. the parent project

Documentation Issue

Improved multi-project support for SAST analyzers

Improved multi-project support for SAST analyzers

SaaS

Self-Managed

GitLab security scans automatically detect code language and run appropriate analyzers. With monorepos, microservices, and multi-project repositories, more than one project can exist in a single GitLab repository. Previously our security tools could only detect single projects in repositories. With this release, our SAST analyzers can now intelligently detect multi-project repositories and run appropriate scanners for each project and report vulnerabilities. This will make it easier and more streamlined for users with multi-project repos to leverage our security tools. Future updates will further improve the dashboard and reporting functionality for these types of projects.

Documentation Epic

Geo supports replicating Versioned Snippets

Geo supports replicating Versioned Snippets

SaaS

Self-Managed

Geo now supports replicating Versioned Snippets to secondary nodes, allowing distributed teams to access them from the closest Geo node, which reduces latency and improves the overall user experience. Additionally, this data can also be restored from a secondary node when failing over to that node.

We currently don’t support verification of these assets, but future support is planned.

Documentation Epic

Omnibus improvements

Omnibus improvements

SaaS

Self-Managed

ARM64 packages are now available for CentOS 8, thanks HiKey!
LDAP credentials can now be encrypted.
Pages now supports HTTPS over PROXYv2 protocol.
registry has been updated to 2.12.0-gitlab, consul to 1.6.6, grafana to 7.3.3, prometheus to 2.22.2, and libjpeg-turbo to 2.0.6.
GitLab 13.7 includes Mattermost 5.29, an open source Slack-alternative whose newest release includes the general availability of Mattermost Omnibus, plus much more. This version also includes security updates and upgrade from earlier versions is recommended.

Documentation

Support for encrypted LDAP credentials

Support for encrypted LDAP credentials

SaaS

Self-Managed

GitLab uses a unified configuration file, for example gitlab.rb in Omnibus GitLab, which makes configuration easy across all of the bundled services. Included in this configuration file are some secrets, like the credentials to authenticate to the LDAP server. While access to this file does require elevated privileges, best practice is to separate secrets from configuration.

Omnibus GitLab and Source installs now support encrypted credentials, with the first credential supported being LDAP. This reduces the sensitivity of the GitLab configuration file, and also helps to achieve customer compliance requirements.

Documentation Issue

Bug fixes

Bug fixes

SaaS

Self-Managed

Some of the notable bug fixes in GitLab 13.7 are:

Bug Fixes

Improved UI for project creation

Improved UI for project creation

SaaS

Self-Managed

The improved user interface for adding a project makes it easier to select between creating a blank project, starting a project from a template, importing an existing project, and creating a CI/CD-only project for external repositories.

Documentation Issue

Limit project and group creation for provisioned accounts

Limit project and group creation for provisioned accounts

SaaS

Self-Managed

To reduce the risk of accidental exposure of intellectual property, GitLab administrators now have greater control over accounts provisioned by their group’s SAML or SCIM integration. In the first iteration of these controls, administrators can prevent their users from creating groups or projects outside of groups to which they do not already belong.

Documentation Issue

Sort issues by the number of issues they are blocking

Sort issues by the number of issues they are blocking

SaaS

Self-Managed

While prioritizing a list of issues in GitLab, it’s often important to determine the critical path and whether an issue is blocking other issues.

With the current issue list, it is impossible to see which issues are blocking other issues. The only way to do so is to open each one and see the list of blockers below the issue description, which is a very time-consuming task!

As of 13.7, you can now use the filter for “Blocking” on any issue list, and you will see a list sorted by the number of blockers.

Sort issues by the number of issues they are blocking

Documentation Issue

Choose to show one file at a time directly from merge requests

Choose to show one file at a time directly from merge requests

SaaS

Self-Managed

Merge request reviews are an essential task to ensure quality code from contributors, as this is where most of the communication between author and reviewer takes place. However, as merge requests become larger and more files are involved, navigation and performance of merge request diffs can become difficult.

GitLab 13.7 introduces the option to show one file at a time in the merge request view. As you navigate to the Changes tab of the merge request, click the gear icon and check the box labeled Show one file at a time. This will display a single file at a time and enable the Prev and Next buttons to navigate among files.

Single file mode provides a cleaner workspace and enhances the reviewer focus on a single file, while improving the performance and navigation of the merge request diff.

Choose to show one file at a time directly from merge requests

Documentation Issue

View Merge Request changes in VS Code

View Merge Request changes in VS Code

SaaS

Self-Managed

When working in VS Code to review a merge request, easily referencing changes often requires checking out a branch and then trying to determine the diff between that branch and the merge target.

With the 3.7.0 Release of GitLab Workflow, merge request changes are available directly in VS Code. This provides quick access to seeing changes for merge requests in your projects.

As we continue working on bringing a complete Code Review experience to VS Code, we’ll be bringing comments on diffs to the extension next.

Documentation Issue

Improved artifact downloads with child pipelines

Improved artifact downloads with child pipelines

SaaS

Self-Managed

Previously, downloading artifacts from a parent pipeline to a child pipeline did not always give the artifacts desired. If two parent pipelines ran around the same time, the child pipeline could download the artifacts from the newer pipeline unexpectedly.

Now you can use the new needs:pipeline syntax to tell the child pipeline the exact pipeline to download artifacts from. You can use it to download artifacts from the parent pipeline, or a different child pipeline in the same parent-child pipeline hierarchy.

Improved artifact downloads with child pipelines

Documentation Issue

Avoid Docker rate limits and speed up your pipelines

Avoid Docker rate limits and speed up your pipelines

SaaS

Self-Managed

For faster and more reliable builds, you can use the Dependency Proxy to cache the container images hosted on Docker Hub. But, when Docker started to enforce rate limits on pull requests from Docker Hub, you noticed that even when your image was pulled from the cache, Docker counted it against your limit. That’s because the Dependency Proxy was only caching the image’s layers (or blobs) and not the manifest, which contains information about how to build a given image. Since the manifest is required, a pull request was still required. This also means that if Docker Hub was unavailable, you couldn’t pull your image.

Moving forward, the Dependency Proxy will cache both the image’s layers and manifest. So, the first time you pull alpine:latest, the image will be added to the Dependency Proxy cache and count as one pull against your rate limit. The next time you pull alpine:latest, it will be pulled from the cache, even if Docker Hub is unavailable and will not count against your rate limit.

Don’t forget, as of milestone 13.6, the Dependency Proxy is available in Core. So, give it a try and let us know what you think. Or better yet, consider contributing to one of the open issues.

Documentation Issue

Quickly find and view generic packages

Quickly find and view generic packages

SaaS

Self-Managed

You can easily publish generic files, such as release binaries, using the GitLab Package Registry. However, if you use the Packages UI and another package manager format, you might have noticed you couldn’t select a tab to quickly view only your generic packages.

We recently added a tab to the Packages UI called Generic so you can limit your view to only your generic packages. We hope this helps you find and validate your packages faster and more efficiently.

Documentation Issue

Use the Dependency Proxy with private projects

Use the Dependency Proxy with private projects

SaaS

Self-Managed

You can use the GitLab Dependency Proxy to proxy and cache container images from Docker Hub. Until recently the feature was only available for public groups, preventing many of you from being able to use it.

You can now use the Dependency Proxy with private projects. You can reduce your reliance on Docker Hub by caching your container images for future use. Because the Dependency Proxy is storing Docker images in a space associated with your group, you must authenticate with your GitLab username and password, or with your personal access token with the scope set to at least read_registry.

Documentation Issue

Define your release description in an external file

Define your release description in an external file

SaaS

Self-Managed

If you create releases in your pipelines via your project’s .gitlab-ci.yml file, you’ve probably found it difficult to maintain each release’s description. In GitLab 13.7, you can now define your release description in a source-controlled or auto-generated file and call it from .gitlab-ci.yml. Doing so loads the file’s content into your release description as Markdown. This makes releases easier for you to create, maintain, and use with version control and is especially useful if you want to auto-generate your changelogs. Huge thanks to Nejc Habjan and Siemens for a great community contribution!

Documentation Issue

Improved MR experience for security scans

Improved MR experience for security scans

SaaS

Self-Managed

With SAST and Secret Detection now available to all usage tiers, we have improved the experience for all GitLab users interacting with Secure scan results in a merge request, making it easier for anyone to access Secure scanning findings. Security scan results previously were only accessible on the Pipeline Overview page and you had to know where to look to find them. Now all merge requests will show if there have been security scans run and help you find the job artifacts. This change does not modify the MR experience for Ultimate users.

Improved MR experience for security scans

Documentation Epic

Special references for vulnerabilities

Special references for vulnerabilities

SaaS

Self-Managed

We introduced vulnerabilities as first-class objects in 12.10. Being a first-class object means each has a unique URL, allowing linking directly to any vulnerability’s details. While a big improvement in visibility and consistency, references to vulnerabilities in issues and epics must still be copy-pasted as manual Markdown links. This makes sharing and referencing vulnerabilities in other areas of GitLab more cumbersome and less efficient than sharing other objects such as issues.

Vulnerabilities can now be linked via special references. They are the first to use a new [object_type:ID] syntax that will eventually extend to other existing references. You can now quickly insert a link to a vulnerability from anywhere you might normally use a special reference such as an issue or merge request comment. For example, type [vulnerability:123] in an issue comment to insert a link to the vulnerability with ID 123 in the same project. You can also prefix the ID with a namespace or project to reference vulnerabilities outside the current project context.

Documentation Issue

GitLab chart improvements

GitLab chart improvements

SaaS

Self-Managed

GitLab instances deployed via the Helm Chart will experience a brief outage during this upgrade due to a change to the way Webservice deployments are managed.

Traffic can now be split by path across different deployments of the GitLab Webservice chart, allowing for division of workloads
nginx has been updated to v0.41.2, a significant update. Due to Pod parameter changes upstream, a brief outage might occur as the underlying pods restart.
registry has been updated to 2.12.0-gitlab, gitlab-kas to 13.7.0, gitlab-runner chart to 0.23.0, gitlab-exporter to 7.1.2
The termination grace period for NGINX is now configurable using terminationGracePeriodSeconds
GitLab Praefect now supports TLS encryption

Documentation

PostgreSQL 12 is the default for new installs

PostgreSQL 12 is the default for new installs

SaaS

Self-Managed

Starting with GitLab 13.3, PostgreSQL 12 has been available as an opt-in option for both Omnibus packages as well as our Helm chart. PostgreSQL 12 offers significant indexing and partitioning benefits, along with broader performance improvements.

In GitLab 13.7, new installations of GitLab will default to PostgreSQL 12 starting with 13.7. To manually upgrade, run gitlab-ctl pg-upgrade.

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.

Documentation Issue

Database queries are faster when using a load balancer

Database queries are faster when using a load balancer

SaaS

Self-Managed

Many database queries are repeated several times and can be cached to improve overall performance. For GitLab, roughly 10% of all queries can be cached. In GitLab 13.7 we enabled database query caching when database load balancing is used, leading to significant overall performance improvements. On GitLab.com this translates to caching ~700,000 queries every minute and improving the overall request time by up to 10%.

For requests that executed more than 100 queries, we improved request duration between 11-31% and cached ~30% of all SELECT statements that would be executed on the database replica otherwise.

Documentation Issue

Performance improvements

Performance improvements

SaaS

Self-Managed

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

Deprecations Deprecations

CentOS 6 is no longer supported

CentOS 6 is no longer supported

CentOS 6 reached end of life in November 2020. GitLab 13.6 was the last supported version for deploying GitLab on CentOS 6. You are advised to upgrade to CentOS 7 or 8. Visit the deprecated OSes page for more information on the supported distributions.

Planned removal date: November 22, 2020

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 one-click GitLab Managed Apps in GitLab 14.0

Deprecate one-click GitLab Managed Apps in GitLab 14.0

In GitLab 13.7 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 update 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.

Planned removal date: December 17, 2020

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:

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

Planned removal date: January 22nd, 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.