14.5

GitLab 14.5 Release

GitLab 14.5 released with infrastructure as code security scanning and group-level merge request approvals

GitLab 14.5 released with infrastructure as code security scanning, group-level merge request approvals, Kubernetes Agent in GitLab Free, project topics and much more!

Today, we are thrilled to announce the release of GitLab 14.5 with infrastructure as code security scanning, group-level merge request approvals settings, Kubernetes Agent available in GitLab Free, project topics, and much more!

These are only a selection of highlights from the 40+ improvements in this release. Read on to check out all of the super updates below.

To preview what's coming in next month’s release, check out our Upcoming Releases page, which includes our 14.6 release kickoff video.

Join us for an upcoming event

GitLab MVP badge

MVP This month's Most Valuable Person (MVP) is awarded to Jonas Wälter

Jonas has been a long-time contributor to GitLab, working along GitLab team members at complex changes to group-level authentication apps, and in 14.5, he has made another stellar contribution to improve project topics. He created over 22 merge requests to enable a separation of topics from tags in GitLab.

While implementing project topics, Jonas ran into a blocker. To enable topics, he had to move the topics out of the tags table in the database. Jonas’s Sharding contribution also unblocked the Sharding group’s efforts. Way to go Jonas! 👏

14.5 Key improvements released in GitLab 14.5

Introducing Infrastructure as Code (IaC) security scanning

Introducing Infrastructure as Code (IaC) security scanning

With Gitlab 14.5 we’re introducing security scanning for Infrastructure as Code (IaC) configuration files. Like all our SAST scanners, we’ve chosen to make this capability available for all customers for free to encourage secure coding practices with the rise of IaC. The initial version of this IaC security scanner supports configuration files for Terraform, Ansible, AWS CloudFormation, and Kubernetes and is based on the open-source Keeping Infrastructure as Code Secure (KICS) project. This new IaC scanning capability joins our existing Kubernetes manifest SAST scanner.

If you’re familiar with GitLab SAST, GitLab’s IaC scanning works exactly the same and supports the same features including a standalone IaC scanning CI configuration file, UI based enablement tool on the Security Configuration Page and support for all our Ultimate tier Vulnerability Management features including Security Dashboards and Merge Request widget. With this new IaC scanning template, we’ve also made it easy to extend our IaC scanning with additional scanners and welcome community contributions using our secure scanner integration framework.

You can read more about IaC scanning in GitLab’s documentation or Checkmarx’s press release.

Introducing Infrastructure as Code (IaC) security scanning

Fine grained permissions control with the CI/CD tunnel

Fine grained permissions control with the CI/CD tunnel

Keeping your clusters’ access safe is paramount for most companies. The CI/CD Tunnel for the GitLab Agent for Kubernetes enables secure access to the cluster from within GitLab CI/CD. Until now, the Tunnel inherited all the permissions of the service account of the installed agent in the cluster. Many users need stricter permission controls, preferably at the user or job level.

In GitLab 14.5, we are pleased to release a generic access impersonation and a CI/CD job impersonation. These impersonations can be specified in the Agent configuration file, and the impersonated account permissions can be managed using Kubernetes RBAC rules.

Fine grained permissions control with the CI/CD tunnel

GitLab Agent for Kubernetes available in GitLab Free

GitLab Agent for Kubernetes available in GitLab Free

Connecting a Kubernetes cluster with the GitLab Agent for Kubernetes simplifies the setup for cluster applications and enables secure GitOps deployments to the cluster. Initially, the GitLab Agent for Kubernetes was available only for Premium users. In our commitment to the open-source ethos, we moved the core features of the GitLab Agent for Kubernetes and the CI/CD Tunnel to GitLab Free. We expect that the open-sourced features are compelling to many users without dedicated infrastructure teams and strong requirements around cluster management. Advanced features remain available as part of the GitLab Premium offering.

Cleaner diffs for Jupyter Notebook files

Cleaner diffs for Jupyter Notebook files

Jupyter notebooks are key to data scientists’ and machine learning engineers’ workflows, but the file structure makes code review challenging. Often, the files can’t be reviewed properly, and users are forced to accept those changes or treat their repositories as stores of data versus collaborative projects.

Now GitLab automatically strips out the noise and displays a cleaner version of the diff for these files. Human-readable diffs make it easier to review the substance of the change, without worrying about the formatting pieces that Jupyter Notebooks need.

Cleaner diffs for Jupyter Notebook files

Geo provides a single command to promote a secondary node

Geo provides a single command to promote a secondary node

When performing a failover, systems administrators use different tools depending on the underlying architecture. On a single-node Geo site, administrators can use the gitlab-ctl promote-to-primary-node command. However, multi-node sites did not support this command and required manual editing of configuration. This was cumbersome for large environments because it required updating dozens of configuration files.

Now, administrators can use gitlab-ctl geo promote on any node of a Geo secondary site to promote it to a primary. In a disaster recovery scenario or planned failover, this saves precious time and reduces potential errors when promoting a secondary site to a primary. This command also makes it easier to script the failover process.

As of GitLab 14.5, the commands gitlab-ctl promote-to-primary-node and gitlab-ctl promote-db are deprecated and will be removed in GitLab 15.0.

Explore project topics tab

Explore project topics tab

In this release, thanks to Jonas Wälter’s contributions, we’ve added a new Explore topics tab in Projects.

  • Topics are sorted by popularity (the number of projects with this topic).
  • Topics can be searched by name and are then sorted by similarity and by popularity.

When you select a topic, you can view its description and avatar, and all of its corresponding projects.

Explore project topics tab

Topic management in the Admin Area

Topic management in the Admin Area

In this release, thanks to Jonas Wälter’s contributions, we’ve introduced several features for administrators to manage project topics in the Admin Area:

  • Add and edit project topics.
  • Search topics based on any string.
  • Add avatars and descriptions to topics (supports Markdown).

Group-level settings for merge request approvals

Group-level settings for merge request approvals

You can now define and enforce values for merge request approval settings at the group level. These values cascade and are used by any projects within the group.

Group-level merge request approvals make it easy for organizations to ensure proper separation of duties across all teams. You only have to specify settings in a single location now, rather than needing to update and monitor every project. When set at the group level, you:

  • Can be confident that projects will use consistent separation of duties workflows.
  • Do not need to manually check that every project has not had its settings modified.
Group-level settings for merge request approvals

Conditional includes with exists keyword

Conditional includes with exists keyword

The include keyword is one of the most popular ones to use when writing a full CI/CD pipeline. If you are building larger pipelines, you are probably using the include keyword to bring external YAML configuration into your pipeline.

In this release, we are expanding the power of the keyword so you can use include with exists in the rules condition. Now, you can decide when external CI/CD configuration should or shouldn’t be included based on when certain files exist in the repository.

Conditional includes with `exists` keyword

Add personal README to profile

Add personal README to profile

You can now add a README section to your GitLab profile! This is a great way to tell others about, your interests, how you work, or anything else you want!

To add a README section, create a new public project with the same name as your user account and add a new README file. The contents of that file are automatically shown on your GitLab profile.

Add personal README to profile

Fine-tune vulnerability check rules

Fine-tune vulnerability check rules

When defining vulnerability check rules, users need a high degree of granularity so they can tailor the rules to only trigger MR approval when it is required per their organization’s security policies. GitLab now supports more granular vulnerability check rules. Users can now define which scanners, severity levels, and vulnerability types are considered when triggering a rule. Additionally, users can set a minimum threshold for the number of vulnerabilities that must meet the criteria before the MR requires approval. By only requiring vulnerability check approvals on MRs that truly need it, this increased granularity allows teams to free up developers and security teams. You can configure these granular vulnerability checks by navigating to the Settings > General > Merge request approvals page in your project.

Fine-tune vulnerability check rules

Additional Secret Detection pattern support

Additional Secret Detection pattern support

We’ve updated the GitLab Secret Detection scanner to detect 47 new ‘well-identifiable’ secret patterns for widely used applications. This brings the GitLab Secret Detection detection up to over 90 detectable patterns.

If you are a SaaS application vendor and your app generates secret tokens with well-identifiable patterns, and you’d like GitLab to be able to detect them, please add your regex pattern and a few invalid sample tokens in a comment on this issue and we’ll get them added to GitLab Secret Detection.

Additional Secret Detection pattern support

14.5 Other improvements in GitLab 14.5

Allow updates to attributes for SAML or SCIM users

Allow updates to attributes for SAML or SCIM users

In previous versions of GitLab, we supported the project_limit and can_create_groups attributes only on newly SAML provisioned users. If users were created using SCIM or is updated in the SAML provider with these attributes, the project_limit and can_create_groups values would not be updated.

Now, if a user is created using SCIM or has an update to these attributes in the SAML provider, these sync to GitLab. This allows the identity provider to act as the single source of truth for core user attributes.

Automatically unblock LDAP users when signing in with other providers (SAML, OAuth, OmniAuth)

Automatically unblock LDAP users when signing in with other providers (SAML, OAuth, OmniAuth)

Transient LDAP errors can cause users to be blocked and unable to log in. If the transient error is resolved, GitLab now rechecks LDAP and unblocks them if another authentication method (such as SAML or OAuth) is configured and used as the sign-in method and the user was blocked using LDAP.

Include Minimal Access role in SAML Group Sync

Include Minimal Access role in SAML Group Sync

Administrators can now specify SAML Group Links with a minimal access role only for the top-level groups. This allows administrators to enhance security by defaulting to minimal access when the user is provisioned and assign more permissive roles at the sub-group level.

Topics selection in project settings

Topics selection in project settings

In this release, thanks to Jonas Wälter’s contributions, adding topics in project settings is easier than ever. Previously, to add a topic, you had to manually enter each topic and multiple topics had to be comma-separated. Now you can select multiple topics from a dropdown list, making topic selection efficient and more convenient.

Topics selection in project settings

Git fetch resource optimizations

Git fetch resource optimizations

We improved the performance of traffic between Workhorse and Gitaly, resulting in git fetch now using fewer GitLab server resources. This change can cause issues on self-managed GitLab if a gRPC proxy is deployed between Workhorse and Gitaly. If you deployed a gRPC proxy between Workhorse and Gitaly, Workhorse can no longer connect. As a workaround, disable the temporary workhorse_use_sidechannel feature flag. If you need a proxy between Workhorse and Gitaly, use a TCP proxy.

Merge commit message template

Merge commit message template

Merge commits can provide important context to the commit history of a project about what was merged. However, if you don’t edit the merge commit prior to merging, other users are forced to navigate to a merge request to gain additional context about why the changes were made.

Project maintainers can now configure a default merge commit message template. This allows projects to specify a standard merge commit, and use variables to provide additional details in these messages. This additional context helps the next developer when trying to understand why the change was made, by providing the potential to make all the relevant information available in the merge commit.

Thanks to Piotr for this amazing contribution!

Merge commit message template

Tables in wikis support block-level elements

Tables in wikis support block-level elements

GitLab 14.1 introduced WYSIWYG editing for tables in the new wiki editor, but the types of content supported in table cells were limited by the underlying Markdown implementation: you couldn’t add block-level elements like lists, code blocks, or pull quotes inside a table. Now, in GitLab 14.5, these block-level elements are fully supported inside table cells. You can insert lists, code blocks, paragraphs, headings, and even nested tables inside a table cell, giving you more flexibility and freedom to format your content to meet your needs.

Tables in wikis support block-level elements

Add pipeline mini graph to the pipeline editor

Add pipeline mini graph to the pipeline editor

Tracking the status of a running pipeline can involve significant context switching because you sometimes have to stop what you are doing to go check the pipeline page. Previously, the pipeline editor only showed the overall pipeline status and provided a link to the pipeline. In this release, we are adding the pipeline mini graph to the pipeline editor to make it easier for you to see the status of individual jobs without leaving the editor.

Add pipeline mini graph to the pipeline editor

Improved UI for runners in the Admin Area

Improved UI for runners in the Admin Area

Previously, if you were a GitLab administrator, you could not easily find runners by instance, group, or project. The search and filter limitations made it difficult and inefficient to locate a runner when troubleshooting CI/CD job execution issues.

This release includes an initial update to the Runners page (Admin Area > Runners). The new layout helps you find runners more quickly and enables GitLab to provide future improvements for runner fleet management. The key improvements in this redesign are tabs that filter the list of runners by type, and indicators that show runners that have not recently connected to GitLab.

Improved UI for runners in the Admin Area

CI/CD Tunnel support for Omnibus installations

CI/CD Tunnel support for Omnibus installations

The CI/CD Tunnel support for self-managed instances installed through GitLab Charts was introduced in 14.0 and significantly improved since then. In this release, we are adding support for Omnibus installations.

The CI/CD Tunnel provides a secure connection from within GitLab CI/CD to your Kubernetes clusters using the GitLab Agent for Kubernetes. This enables users to continue using their existing tools and processes, and adopt the Agent for a robust and safe setup.

Basic authentication for alert HTTP endpoints

Basic authentication for alert HTTP endpoints

In the past, you needed a bearer token to authenticate to an alerts HTTP endpoint. Beginning with this release, you can also authenticate with Basic HTTP authentication, either through the headers or in the URL.

Return alert ID in POST responses for alerts

Return alert ID in POST responses for alerts

Currently, when you POST an alert using the generic alert HTTP Endpoint the response is a simple 200 upon a successful POST. If you want to reconcile your current alert workflows, you may need to see additional information returned in the POST response. In this release, we added the alert ID (iid) to the response, enabling you to see your specific alerts by a unique ID.

Static Analysis analyzer updates

Static Analysis analyzer updates

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

  • semgrep updated to version 0.72.0 - MR, Changelog
    • various bug fixes for timeouts, crashes, and rule corrections. See changelog link for more details.
  • flawfinder internal packages updated to version 2.14.7 - MR, Changelog
  • gosec updated to version 2.9.1 - MR, Changelog
    • Fix the SBOM generation step in the release action
    • Phase out support for go version 1.15 because current ginko is not backward compatible
  • sobelow internal packages updated - MR, Changelog
    • We thank @rbf for their contributions (1,2,3) to our Sobelow analzer which enables new detection rules, and opens up the door for future improvements and additional rules in the future.
  • PMD updated to version 6.40.0 - MR, Changelog
    • Apex language support to v54.0
    • Various improvements and bugfixes for rulesets.
  • spotbugs updated to version 4.5.0 - MR, Changelog
    • false negative fixes

If you include the GitLab managed vendored SAST template (SAST.gitlab-ci.yml) you do not need to do anything to receive these updates. However, if you override or customize your own CI template, you need to update your CI configurations. To remain on a specific version of any analyzer, you can pin to a minor version of an analyzer. Pinning to a previous version prevents you from receiving automatic analyzer updates and require you to manually bump your analyzer version in your CI template.

Omnibus improvements

Omnibus improvements

  • With CentOS 8 EOL approaching, we have added support for AlmaLinux as a replacement in GitLab 14.5. AlmaLinux is backed by a company with a long track record of building an enterprise Linux compatible distribution and has the processes in place to sustain it. This aligns to our preference for the boring solution.
  • GitLab will now publish an ARM64 version of GitLab Enteprise Edition to the AWS Community AMI catalog. AWS is seeing a rise in adoption of AWS Graviton2 (ARM64), so we want to make sure GitLab EE will be usable for those users accessing the AWS Community AMI catalog. This documentation contains relevant information for using the AWS community AMIs.
  • GitLab 14.5 will provide packages for openSUSE Leap 15.3. OpenSUSE Leap 15.2 will reach its end of life on December 31st, 2021, therefore we want to provide OpenSUSE 15.3 in advance so users have a few milestones to make the move to a more recent version of OpenSUSE.

Audit events for group SAML configuration changes

Audit events for group SAML configuration changes

GitLab now records audit events for changes to additional group SAML settings. Events are created when changes are made to:

  • Enabled status
  • Enforcing SSO-only authentication for web activity
  • Enforcing SSO-only authentication for Git and Dependency Proxy activity
  • Enforcing users to have dedicated group-managed accounts
  • Prohibiting outer forks
  • Identity provider SSO URL
  • Certificate fingerprint
  • Default membership role
  • SSO-SAML group sync configuration

These events give you visibility on who configured or changed group SAML settings, and when. They can be used in an audit to show that controls were correctly set and then never changed, or they can identify any changes that were made that need to be further examined.

Contribution calendar aligned to configured timezone

Contribution calendar aligned to configured timezone

Previously, your contribution calendar was aligned with the server’s timezone instead of your local timezone. Large differences between the two timezones could make it appear that you contributed a day earlier or later than you actually did.

Now, contribution calendars are aligned with your local zone, if set. Others can hover over activity to view your local date and time information, to compare their local timezone with your own.

Thanks to Dave Barr for this contribution!

Contribution calendar aligned to configured timezone

Manage project topics with the API

Manage project topics with the API

In this release, thanks to Jonas Wälter’s contributions, adding topics in project settings is easier than ever. In addition to the latest project topic management features in the UI, you can now use the API to retrieve topics by list or ID. We’ve also made it possible for administrators to create or edit topics through the API. This introduces full parity between project topic management in the UI and API.

In previous releases we added the ability to filter Value Stream Analytics by attributes such as labels, milestones, and assignees. In this release, we’ve enhanced this by adding deep links for query parameters. This creates a hyperlink from the custom query that you can send as a URL to your peers for collaboration, or save as a bookmark for future use.

GitLab Workflow authentication with environment variables

GitLab Workflow authentication with environment variables

In automated development environments, like Gitpod, configuration of GitLab Workflow for Visual Studio Code requires loading the editor and then setting the personal access token for GitLab each time. This process is time consuming, error prone, and leads to multiple or duplicate use of access tokens.

With the release of GitLab Workflow v3.36.0 the extension now supports configuration via environment variables. Using environment variables enables you to configure the authentication once. Each VS Code instance is then able to authenticate even when the previous VS Code instance has been deleted.

Sticky toolbar when editing wiki pages

Sticky toolbar when editing wiki pages

When you edit long wiki pages, the editor grows vertically to fit your content. In previous versions, the editor could become so long that the formatting toolbar icons disappeared. When writing in raw Markdown, this can be frustrating but you can overcome it using keyboard shortcuts. However, the toolbar is a much more critical component of the new rich Markdown editor, so having this UI unavailable on the screen requires you to scroll vertically, away from your content, to access core features.

Now, in GitLab 14.5, the formatting toolbar remains fixed at the top of the input field, allowing you easy and persistent access to these convenient features, even when editing very long documents.

Thank you Mehul Sharma for contributing this helpful improvement!

View file tree when reviewing in Visual Studio Code

View file tree when reviewing in Visual Studio Code

When you review a merge request in GitLab Workflow extension for VS Code, it provides a flat file list to navigate the changes. The flat file list lacks context, and can make it hard to understand where the changes are. In large codebases where files might have the same names across different directory paths, this can be even more problematic when reviewing.

With the release of v3.37.0, the GitLab Workflow extension now provides a toggle to switch between a flat list and a file tree view. This file tree view brings additional path information to help you navigate the changes, and get a complete picture of the merge request.

Thanks to Liming Jin for the amazing contribution!

View file tree when reviewing in Visual Studio Code

GitLab Runner 14.5

GitLab Runner 14.5

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

Extract package metadata for npm packages

Extract package metadata for npm packages

You can use the GitLab Package Registry to publish and share npm packages alongside your source code and pipelines. Prior to this release, however, GitLab did not extract all of the relevant metadata detailed in your package.json file. This is especially problematic when npm or Yarn relies on one of those fields. For example, the bin field defines executables to insert in $PATH. Without that field, your executables do not work.

As of this release, GitLab now extracts the abbreviated metadata for npm packages, including the bin field and others. If you publish packages that have one or more executable files to install into the $PATH, you can now rely on the GitLab Package Registry to work seamlessly. Please note that this change applies to new packages only. Any packages already published to the registry must be updated for the change to take effect. In addition, GitLab only extracts the abbreviated metadata, which excludes certain fields. GitLab-#344107 proposes extracting the full metadata set.

Order deployment by deployed time

Order deployment by deployed time

Currently, the environment page sorts the list of deployments by the Created date, which is associated with the commit SHA change. To make it easier to view deployments over time, we have changed the default sorting order of this list to be by the finished_at field rather than the date of the commit. You can now see the running and most recently completed deployments at the top of the page and the rest of your deployments in descending order by the deployed time.

Order deployment by deployed time

Restrict incident creation permissions to at least the Reporter role

Restrict incident creation permissions to at least the Reporter role

You may have experienced a time where you created an incident when you actually meant to create an issue. Incidents are a specific issue-type, with a unique user interface and workflow that represent service disruptions or outages. In this release, only users with at least the Reporter role can create incidents. Restricting these permissions will help minimize the number of accidentally-created incidents.

Restrict incident creation permissions to at least the Reporter role

New GitLab access token prefix and detection

New GitLab access token prefix and detection

With GitLab 14.5 we have updated the GitLab Personal Access Tokens and Project Access Tokens to include a standard prefix, glpat- by default for both GitLab.com and GitLab self-managed instances. We’ve also updated our Secret Detection scanning to detect this new pattern which will help protect you against accidentally leaked GitLab access tokens in commits.

This improvement helps make it easy to detect GitLab tokens leaked in commits and builds on community contribution improvements added in Gitlab 13.7 that allowed Admins to set Personal Access Token prefixes at the instance level, shoutout to @max-wittig and @dlouzan at Siemens for this contribution! Existing access tokens will not be modified but any new tokens will follow this new pattern or the custom pattern set by your self-managed GitLab instance.

If you would like to detect GitLab Personal Access Tokens and Project Access Tokens you can use the following regex detection pattern: glpat-[0-9a-zA-Z\-]{20}.

New GitLab access token prefix and detection

GitLab chart improvements

GitLab chart improvements

In GitLab 14.5, we now support the ability to set the Ingress API version via Helm values. This ability supports our work towards Kubernetes 1.22. When Kubernetes 1.22 is fully supported, when a user installs our Chart on a 1.22 cluster, a newer supported version on Ingress is be chosen. Users can manually specify the newer supported version if not installing against a live cluster, like when running a helm template.

Bug fixes

Bug fixes

Some of the notable bug fixes in 14.5 are:

Performance improvements

Performance improvements

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

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

Usability improvements

Usability improvements

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

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

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

Deprecations Deprecations

New deprecations and the complete list of all features that are currently deprecated can be viewed in the GitLab documentation. To be notified of upcoming breaking changes, subscribe to our Breaking Changes RSS feed.

  • GraphQL API Runner status will not return `paused`
  • Package pipelines in API payload is paginated
  • Update to the container registry group-level API
  • `promote-db` command from `gitlab-ctl`
  • `dependency_proxy_for_private_groups` feature flag
  • `pipelines` field from the `version` field
  • Known host required for GitLab Runner SSH executor
  • `promote-to-primary-node` command from `gitlab-ctl`
  • Support for SLES 12 SP2
  • SaaS certificate-based integration with Kubernetes
  • Value Stream Analytics filtering calculation change
  • `defaultMergeCommitMessageWithDescription` GraphQL API field
  • `Versions` on base `PackageType`
  • Changing an instance (shared) runner to a project (specific) runner
  • Self-managed certificate-based integration with Kubernetes
  • Removals and breaking changes Removals and breaking changes

    The complete list of all removed features can be viewed in the GitLab documentation. To be notified of upcoming breaking changes, subscribe to our Breaking Changes RSS feed.

    Important notes on upgrading to GitLab Important notes on upgrading to GitLab 14.5

    • The Task Runner pod is used to execute periodic housekeeping tasks within the GitLab application, and is often confused with the GitLab Runner. To remove confusion, the Task Runner is renamed to Toolbox in GitLab 14.5. This results in the rename of the sub-chart gitlab/task-runner to gitlab/toolbox. The resulting pods are named according to the pattern {{ .Release.Name }}-toolbox, which often results in pods named gitlab-toolbox. You can locate them with the label app=toolbox.

    • Sidekiq deployments were changed from having a -v1 suffix to -v2. Due to the deployment name changing, Sidekiq shutdown of the old pods and start of the new is handled by separate deployments, and as a result there could be a period of time during the upgrade where there are no Sidekiq pods running. Sidekiq works on asynchronous jobs, so impact might be a delay in background job processing like running new CI jobs and updating merge requests diffs. We are implementing podAntiAffinity in such way that allows to spread out Sidekiq pods across the cluster.


    • An extra step for finalizing background migration jobs over the merge_request_diff_commits table may result in extra time required during an upgrade to 14.5. Large instances with a large number of merge request diff commits, may be interested to perform an optional manual operation to save additional space. For more information, please check the version-specific upgrading instructions for 14.5.

    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 Unsplash free license

    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