14.2

GitLab 14.2 Release

GitLab 14.2 released with the Build Cloud for macOS beta and Markdown preview

Key improvements in Gitlab 14.2 include the introduction of the Build Cloud for macOS beta, Markdown preview, expanded Gitpod integration, new DevOps adoption metrics, and much more

Today, we are excited to announce the release of GitLab 14.2 with introduction of the Build Cloud for macOS beta, Markdown preview, expanded Gitpod integration, new DevOps adoption metrics, and much more!

These are just a few highlights of the 50+ improvements in this release. Read on to check out all of the great updates below.

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

Join us for an upcoming event

GitLab MVP badge

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

Cornelius added support for opening code changes directly in Gitpod when viewing a merge request. In fact, this release blog post was created and edited with Gitpod! Cornelius initially helped add an option to open a project in Gitpod to the repository overview page in GitLab 13.5.

That capability has now expanded so that you can launch Gitpod directly from the merge request page to speed up your reviews and reduce the need for context switching in your local development environment.

Read the full release post below for more details. Thanks for your contributions Cornelius! We believe cloud development environments like Gitpod reduce barriers and make it easier for everyone to contribute.

14.2 Key improvements released in GitLab 14.2

GitLab Build Cloud for macOS beta

GitLab Build Cloud for macOS beta

Today, Apple ecosystem developers on GitLab SaaS need to install, manage, and operate GitLab Runner on their own macOS systems to execute CI/CD workflows.

Now, you can build applications on the new Build Cloud beta for macOS, a GitLab Runner-powered build platform integrated with GitLab SaaS CI/CD.

Access to the beta is initially limited to approved customers and open source community program members. For details, check out this blog post.

You can always install macOS Runner on any on-premise Apple environment, MacStadium, or AWS.

GitLab Build Cloud for macOS beta

Launch a preconfigured Gitpod workspace from a merge request

Launch a preconfigured Gitpod workspace from a merge request

The Gitpod integration, introduced in GitLab 13.5, helps you manage your complicated development environments. Once you define your project’s configuration in code, you can launch a prebuilt, cloud-based development environment with a single click. This convenient workflow has made it faster than ever to generate new changes, but launching a Gitpod environment to review an existing merge request meant building an environment against the main branch before switching to the target branch and building again.

Now, in GitLab 14.2, you can launch Gitpod directly from the merge request page, preconfigured to use the target branch, to speed up your reviews and reduce the need for context switching. Enable the Gitpod integration, and your merge requests display a grouped Open in button, so you can open the merge request in either the Web IDE or Gitpod.

Thanks to Cornelius Ludmann from Gitpod for this contribution!

Launch a preconfigured Gitpod workspace from a merge request

Track use of dependency scanning and fuzz testing

Track use of dependency scanning and fuzz testing

Track which groups across your organization have enabled dependency scanning and fuzz testing. Previously, you could only track adoption of these GitLab features through the API.

Now you can compare adoption across your groups from the DevOps Adoption table in the UI and sort the table to easily find which groups are using these security features.

Track use of dependency scanning and fuzz testing

Preview Markdown live while editing

Preview Markdown live while editing

Markdown is a fast and intuitive syntax for writing rich web content. Until it isn’t. Luckily, it’s easy to preview the rendered output of Markdown to ensure the accuracy of your markup from the Preview tab. Unfortunately, the context switch required to move between the raw source code and the preview can be tedious and disruptive to your flow.

Now, in both the Web IDE and single file editor, Markdown files have a new live preview option available. Right-click the editor and select Preview Markdown or use Command/Control + Shift + P to toggle a split-screen live preview of your Markdown content. The preview refreshes as you type, so you can be confident that your markup is valid and will render as you intended.

Preview Markdown live while editing

Use CI/CD variables in include statements in .gitlab-ci.yml

Use CI/CD variables in include statements in .gitlab-ci.yml

You can now use variables as part of include statements in .gitlab-ci.yml files. These variables can be instance, group, or project CI/CD variables.

This improvement provides you with more flexibility to define pipelines. You can copy the same .gitlab-ci.yml file to multiple projects and use variables to alter its behavior. This allows for less duplication in the .gitlab-ci.yml file and reduces the need for complicated per-project configuration.

Use CI/CD variables in `include` statements in `.gitlab-ci.yml`

Improved vulnerability tracking for GoSec, Semgrep, and Brakeman analyzers

Improved vulnerability tracking for GoSec, Semgrep, and Brakeman analyzers

Over the course of a project’s life cycle, code is moved around. Refactoring, additions to the code base, removals, will all happen. Our current fingerprinting of findings is too coarse and results in a lot of duplicated findings over time as code is moved around. SAST and Secret Detection findings currently use location within a file to declare where they exist within a codebase. Over time we lose the ability to track the movement of a finding as lines are added to, or removed from the file above the finding in question. This reality makes it hard to discern findings that are truly new, especially in the context of a merge request.

We’ve developed a new vulnerability tracking algorithm that is more advanced and looks at the signature of a vulnerability rather than just its location. This new tracking improves the accuracy of identifying the same vulnerability that has moved locations due to code refactoring.

We’ve now brought this new vulnerability tracking system to our GoSec (Go) analyzer, Semgrep (JavaScript, TypeScript, React, and Python), and Brakeman (Ruby and Ruby on Rails) analyzers. We will continue expanding coverage of this new vulnerability tracking system to other language analyzers in future releases.

Improved vulnerability tracking for GoSec, Semgrep, and Brakeman analyzers

Stageless pipelines

Stageless pipelines

Using the needs keyword in your pipeline configuration helps to reduce cycle times by ignoring stage ordering and running jobs without waiting for others to complete. Previously, needs could only be used between jobs on different stages.

In this release, we’ve removed this limitation so you can define a needs relationship between any job you want. As a result, you can now create a complete CI/CD pipeline without using stages by including needs in every job to implicitly configure the execution order. This lets you define a less verbose pipeline that takes less time to create and can run even faster.

Stageless pipelines

New GitLab Agent for Kubernetes UI

New GitLab Agent for Kubernetes UI

The GitLab Agent for Kubernetes allows a secure bi-directional connection between GitLab and any Kubernetes cluster. Until now, registering a new Kubernetes Agent required writing GraphQL queries.

As of GitLab 14.2, GitLab ships with a user-friendly user interface and a registration form to help you get started with the Kubernetes Agent with ease.

New GitLab Agent for Kubernetes UI

Create a GitLab branch from a Jira issue

Create a GitLab branch from a Jira issue

Users of the GitLab.com for Jira Cloud application can now create GitLab branches directly from a Jira issue’s development panel. This enables developers to begin work on issues without having to switch tools and lose context.

Create a GitLab branch from a Jira issue

Export membership CSV report from top-level group

Export membership CSV report from top-level group

You can now export a report that lists all members in a given group. This was already possible at the instance level and we are very excited to bring it to the top-level group!

This report contains information such as users, email addresses, and permissions levels, all describing the users who have access to the group.

This report allows you to quickly get visibility into who is in a group, and what type of access is possible for your groups and projects, enabling you to rapidly identify required updates. This is a great step toward bringing a similar, high-quality experience to our GitLab.com users, in what was previously only available on self-managed GitLab.

Export membership CSV report from top-level group

Group Migration achieves parity with group import/export

Group Migration achieves parity with group import/export

The new GitLab Migration feature can now migrate an entire group with all its subgroups and related data. The data migrated includes everything contained in group exports, making this a much easier way to migrate entire groups. The pre-existing group import/export is a two-step process that requires exporting a file and then importing it into another GitLab instance.

Now, users can initiate a group migration with a single click. Migration also includes all the subgroups and their data, which previously required separate export and import processes for each subgroup.

Group Migration achieves parity with group import/export

Hide all issues created by banned users

Hide all issues created by banned users

In a previous release, we added a new banned user state. In this release, we now also hide all issues created by a banned user. This is extremely helpful in cases where a malicious user bombards GitLab instances with spam issues. These can now be hidden.

Hide all issues created by banned users

View historical CI pipeline minute usage

View historical CI pipeline minute usage

Before GitLab 14.2, the CI pipeline minutes usage on the Usage Quotas page only showed the current month’s usage. This data would reset every month and there was no way to view activity from the past months for analyzing historical usage.

Now there are two charts that show historical CI pipeline minutes usage by month or by project, so you can make informed decisions about your pipeline usage.

View historical CI pipeline minute usage

14.2 Other improvements in GitLab 14.2

Add compliance framework labels to group-level project list

Add compliance framework labels to group-level project list

Compliance framework labels are now shown on the group-level project list. This allows you to identify at a glance which projects have specific compliance frameworks applied.

Add compliance framework labels to group-level project list

Assign compliance framework to project using GraphQL

Assign compliance framework to project using GraphQL

You can now set a compliance framework for projects using the GraphQL API in addition to the GitLab UI. This makes it easy to do bulk updates to many projects at once and supports those who prefer to create and configure projects programmatically.

Group access tokens as Git credentials

Group access tokens as Git credentials

Customers with Rails console access can create group access tokens to perform actions at the group level, and manage projects in the group with a single token. Previously, using a group access token for Git credentials caused an authentication failure. In this release, we’ve:

See the number of items in each stage in project-level Value Stream Analytics

See the number of items in each stage in project-level Value Stream Analytics

You can now more easily see the volume of work in each stage. Value Stream Analytics for projects now shows the total number of workflow items in each stage of a value stream.

See the number of items in each stage in project-level Value Stream Analytics

View all Value Stream Analytics metrics for projects

View all Value Stream Analytics metrics for projects

Until now, project and group-level metrics in value stream management displayed different data sets.

In this release, you can view the same metrics on the project and group level, based on your GitLab subscription. Both project and group analytics now include New Issues, Commits, Deploys, Deployment Frequency, Lead Time (Premium and Ultimate), and Cycle Time (Premium and Ultimate).

View all Value Stream Analytics metrics for projects

Edit issue title from an issue board

Edit issue title from an issue board

Editing an issue in an issue board currently requires many steps and takes you out of your workflow. We’ve added an easy way to edit an issue’s title right in the issue board, without navigating to another page. To edit the title, in the right sidebar, select the issue, then select Edit.

Edit issue title from an issue board

Format wiki pages more easily

Format wiki pages more easily

The new WYSIWYG editor has made writing Markdown in your wiki easier than ever. However, the toolbar’s position in the editor made formatting text on longer pages tedious and repetitive.

In GitLab 14.2, the most frequently used formatting options (bold, italic, strikethrough, and code) display in a floating menu above your text selection. By limiting the distance you have to move your cursor while formatting, you can work more efficiently. Spend more time focusing on your content, and less on scrolling up and down the page.

Format wiki pages more easily

GitLab Runner 14.2

GitLab Runner 14.2

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

Show pipeline IID in the pipelines page

Show pipeline IID in the pipelines page

The pipeline IID gives the internal ID of a pipeline relative to the project that triggered it, and it increments for every new pipeline in the project. The pipeline IID increments much slower than the pipeline ID, which increments by one for every pipeline in the whole GitLab instance. This makes the pipeline IID a more useful value for use cases like versioning project releases based on pipelines, tracking pipelines based on their run order in the project, project pipeline metrics, etc.

To help improve the experience of using the pipeline IID, we are adding an option to the pipelines page to change the display from the ID, to the internal project IID. Now you can easily see which pipeline matches the IIDs you are using.

Use deploy tokens with the Dependency Proxy

Use deploy tokens with the Dependency Proxy

To reduce your reliance on external dependencies and reduce build times, you can use the GitLab Dependency Proxy to cache frequently used images from Docker Hub.

You can now use deploy tokens when authenticating to use the GitLab Dependency Proxy. Previously, you had to authenticate with predefined environment variables. Such variables are tied to a user’s permissions and therefore not ideal for production pipelines. Deploy tokens are easier to manage for authentication. With deploy tokens, you don’t have to worry about adding someone to your project. You can create a token, set the desired scope, and then rotate users according to your organization’s policies.

Simply create a group deploy token and user name with the scope set to read_registry and write_registry. Then you can login to the GitLab.com registry with your deploy token username and password, and proxy and cache container images from Docker Hub.

Expose deployment_tier in the Pipeline events webhook

Expose deployment_tier in the Pipeline events webhook

In GitLab 13.10, we introduced the concept of deployment tier. In this release, we added deployment_tier in the Pipeline events webhook so that you can use it in your automations.

Add quick action for updating incident severity

Add quick action for updating incident severity

You can now update the incident issue’s severity with the /severity quick action. For example, using the /severity 3 quick action in an incident issue sets the severity to 3. This handy keyboard shortcut enables incident responders to quickly update the incident and get right back to resolving the problem.

Add quick action for updating incident severity

Improved usability of Security & Compliance Configuration page

Improved usability of Security & Compliance Configuration page

GitLab has greatly expanded Security and Compliance functionality over the last year. As features have grown, so have the number of related configuration options. The current Security & Compliance Configuration page has expanded beyond what it was originally designed to accommodate, making finding the right option cumbersome.

To address this, we have redesigned the Security & Compliance Configuration page. Not only does the new design improve usability, it provides a flexible pattern that will scale as we continue to add to our security and compliance offerings.

Improved usability of Security & Compliance Configuration page

SAST Go analyzer updated to support Go 1.16

SAST Go analyzer updated to support Go 1.16

We have updated our Static Application Security Testing (SAST) Go analyzer, GoSec, to support Go 1.16. This update introduces support for Go projects requiring this version of Go but also limits GOPATH shimming to only projects without Go modules. Should you require GOPATH shimming you can now pin to a minor version of an analyzer using GoSec version 3.1.3. Pinning to a previous version will prevent you from receiving automatic analyzer updates and require you to manually bump your analyzer version in your CI template.

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.2. These updates bring additional coverage, bug fixes, and improvements.

If you:

GitLab chart improvements

GitLab chart improvements

GitLab 14.2 also includes a reformatting of global.imageXxYy to global.image.x. This simplifies the different global image commands. For example:

  • global.imagePullPolicy becomes global.image.pullPolicy
  • global.imagePullSecrets becomes global.image.pullSecrets.

This will continue to be improved with future iterations.

Add file path copy ability to code search results

Add file path copy ability to code search results

Users often want to search for files and then open them in their editor of choice. In GitLab 14.2, we added a file path copy icon beside the file path of the search results. Users can click the icon to copy the file path and paste it to their editors to open the file.

Add file path copy ability to code search results

Timeout state search tips for Global Search Result page

Timeout state search tips for Global Search Result page

Sometimes when searching broadly across GitLab, timeouts can occur. We implemented a search timeout page to help users in these situations and take advantage of stronger search criteria.

Add pronunciation to GitLab profile page

Add pronunciation to GitLab profile page

You can now add pronunciation to your user profile. In distributed teams where team members are from different countries, it can be difficult to determine how to say someone’s name correctly. This will help others know how to pronounce your name.

Display local time on user’s profile

Display local time on user’s profile

Local time is now displayed on user profiles. In previous releases, you could set the timezone but it was not visible throughout GitLab. This improvement is extremely helpful for distributed teams to help others know when others are likely to be available.

Display local time on user's profile

Hide application secrets

Hide application secrets

Previously, the Secret field was visible in the GitLab UI on an application’s configuration page. To improve security, we have hidden this field from the UI and added a Copy button. You can then copy the secret and store it in a secured location. This makes sure the secret is not visible in clear text for anyone looking at the screen.

Hide application secrets

Show selected label when filtering Jira issues

Show selected label when filtering Jira issues

Users can now see which labels they used to filter their Jira issues list. This change improves usability by allowing users to have full context of the list they are viewing.

Show selected label when filtering Jira issues

View projects that use custom integration settings

View projects that use custom integration settings

In this release, we are making the management of project integration configuration much easier! GitLab administrators can now see a list of projects that are not using the default integration configuration. This functionality helps administrators ensure that projects have the right data from integrated systems.

View projects that use custom integration settings

Immediately delete projects scheduled for delayed deletion

Immediately delete projects scheduled for delayed deletion

Delayed project removal protects your data by placing deleted projects in a read-only state so you can restore them. Until now, delayed project deletion has been disabled on GitLab.com because there has been no way to immediately delete a project when necessary.

In this release, we’ve added an instance setting to enable delayed deletion by default for all new projects. You can also immediately permanently delete projects that are scheduled for delayed deletion without globally disabling the setting.

Delayed project deletion is now enabled by default for new groups and projects created on GitLab.com, and group owners can disable it.

Upload and attach files in the new wiki editor

Upload and attach files in the new wiki editor

GitLab 14.1 introduced the ability to upload and insert images into the new wiki content editor.

Now in GitLab 14.2, you can upload and attach .zip, .pdf, .txt, and other binary files in the same way. This brings us one step closer to feature parity with the classic wiki editor, and unlocks additional ways for you to collaborate on rich content in your wiki pages.

Upload and attach files in the new wiki editor

Show linked pipelines in the mini pipeline graph

Show linked pipelines in the mini pipeline graph

The pipeline mini graph shows you the status of each stage in your pipeline and gives you a quick and easy way to navigate to any job. Linking multiple pipeline mini graphs together provides you with the same functionality for related upstream and downstream pipelines.

In this release, you have the ability to see linked upstream and downstream pipelines in the mini graph in new areas in the GitLab UI: the pipeline tab, the project pipeline page, the commit page, and the commit page’s pipeline tab.

Share your container registry without sharing source code

Share your container registry without sharing source code

When you are configuring your project, you can control feature-specific permissions for things like issues or the repository. For example, in a public project, you can still limit repository access to project members only.

The problem is that although you can control several features like this, for the container registry, you only had the ability to toggle the feature on and off. This is problematic for many organizations that would like to control access to the container registry separately from the repository.

Now you can avoid that problem by configuring your project to define an access level for your container registry independent of the access level of your repository and other features. You can do this using the project’s API and the user interface.

Automatic creation of configuration file for CI/CD Tunnel

Automatic creation of configuration file for CI/CD Tunnel

Until now, users of the GitLab Agent for Kubernetes CI/CD Tunnel had to add a corresponding kubeconfig configuration file to a CI/CD job manually. Creating the kubeconfig file required editing the CI/CD pipeline definition, a knowledge of the Agent ID, and an understanding of how a kubeconfig is structured. It also introduced boilerplate code into the CI/CD pipeline definition.

GitLab now injects a kubeconfig file that contains all the available agent connections for the given project. A user only has to choose the right kubecontext to use.

View Terraform state parameters in the UI

View Terraform state parameters in the UI

The GitLab managed Terraform state can be accessed from GitLab CI/CD without any special configuration. To access the same state from a local machine, Terraform must be initialized with several parameters.

Finding the right parameters can be a tedious and error-prone process, so we now provide a simple user interface on the Terraform State list page that shows the command to use to initialize a Terraform state access from the command line. You can access this view from the Infrastructure > Terraform menu.

Email specific users in an escalation policy

Email specific users in an escalation policy

When creating the escalation policy for alerts, it’s useful to email a specific user in addition to the on-call user. In this release, we added the ability for teams to define the user to contact, even if that user isn’t part of the on-call rotation.

Email specific users in an escalation policy

SAST .NET analyzer updated to support Visual Studio 2019 projects

SAST .NET analyzer updated to support Visual Studio 2019 projects

We have updated our Static Application Security Testing (SAST) for .NET, Security Code Scan, to migrate to a new Alpine base image for this analyzer for consistency as well as improved stability, performance, and security. This generally should not cause problems, however if you leverage before_script with the security-code-scan-sast job, you may need to update your before_script to resolve any incompatible function calls.

We’ve also updated Security Code Scan to its latest major version (v5). This adds support for projects built with Visual Studio 2019 and is a major upgrade to a new inter-procedural taint analysis engine. Due to the major upgrade, we are making this opt-in for now and a future release will update this version by default. To begin using this updated version, please leverage the following override to pin Security Code Scan to the new version: SAST_ANALYZER_IMAGE_TAG: 3.

In future versions of GitLab, we will update the default version of Security Code Scan to this new version, at which point you will no longer need to use the above code snippet.

Semgrep SAST Analyzer for C

Semgrep SAST Analyzer for C

In GitLab 13.12 we released Semgrep for Javascript, TypeScript, and Python. Today we’re expanding the Semgrep analyzer to support projects written in the C language. Developed in partnership with r2c, the team behind Semgrep who share our mission to help developers write more secure code. After an extensive beta with hundreds of customers trying out our experimental analyzer, we’re ready to start the transition to Semgrep. With 14.2, we’re updating our managed ‘SAST.gitlab-ci.yml’ CI template to automatically run this new analyzer alongside our existing C/C++ analyzer, Flawfinder. In a future release, we will fully disable Flawfinder once we add support for C++, but for now it will work in unison with Semgrep. We’ve done work to deduplicate findings, so you should not notice any difference in findings. If you include our ‘SAST.gitlab-ci.yml’, you don’t need to do anything to start benefiting from the Semgrep analyzer. However if you override or manage your own SAST CI configuration, you should update your CI configuration. We are excited about the future of this transition to bring you fast and wide coverage Static Application Security Testing (SAST). We’ll continue to expand the Semgrep analyzer through new security detection rules as well as expanding coverage to other languages. We’ve created a feedback issue where you can share your experience with this transition or ask questions.

Geo verifies replicated versioned snippets

Geo verifies replicated versioned snippets

Geo automatically verifies the data integrity of replicated versioned snippets. This ensures that snippets are not corrupted in the transfer or at rest. If Geo is used as part of a disaster recovery strategy, this protects customers against data loss.

In the next iteration, we will implement automatic healing once a mismatch in verification is detected.

Geo’s verification capabilities are implemented generically in Geo’s replication framework and we are planning to bring verification to all other replicated data types.

Note: This feature was originally announced by mistake in the GitLab 13.11 release post. It was available behind a feature flag, but not enabled by default. In GitLab 14.2, we removed the feature flag and enabled versioned snippet verification.

Omnibus improvements

Omnibus improvements

  • GitLab 14.2 includes Mattermost 5.37, an open source Slack-alternative whose newest release includes a new beta feature, Collapsed Reply Threads. Users may experience bugs, and current known issues are documented. Additionally v5.37 includes support for emoji standard v13.0. If you have added a custom emoji in the past that uses one of the new system names, then it is going to get overwritten by the system emoji. The workaround is to change the custom emoji name. Also, parts of Incident Collaboration are now available to all Mattermost editions. As part of this update, Incident Collaboration will require a minimum server version of v5.37.
  • GitLab 14.2 supports two new features for more secure Patroni patterns. This includes support of TLS for the Patroni API, allowing users to use TLS for a more secure communication. GitLab 14.2 also includes support for allowlist and allowlist_include_members with Patroni. This allows users to limit write access to the Patroni REST API by IP address, a further protection in addition to the authentication measures.

Load balancing for Sidekiq enabled by default

Load balancing for Sidekiq enabled by default

Sidekiq, the job scheduler used by GitLab, creates a number of read-only jobs. When using a database cluster that includes a read and writable primary node and one or many read-only nodes, these jobs do not have to be executed on the primary node. Instead, they can benefit from database load balancing and execute on read-only nodes. This reduces the overall load on the primary database node and can result in performance improvements.

Sidekiq load balancing was introduced in GitLab 14.1 and is enabled by default in GitLab 14.2.

Bug fixes

Bug fixes

Some of the notable bug fixes in 14.2 are:

Performance improvements

Performance improvements

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

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

Some of the notable usability improvements in GitLab 14.2 are:

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.

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

  • GitLab 14.2 contains long running background migrations that swap columns on tables potentially affected by primary key overflows. Read the GitLab 14.2 update instructions for further guidance and to learn what tables are affected.

  • Before upgrading to GitLab 14.2, you must upgrade to either the latest patch release of GitLab 14 (14.0.Z) or the latest patch release of GitLab 14.1 (14.1.Z). This is important because these releases contain batched background migrations as part of our ongoing effort to address primary key event overflow risks. These background migrations included in the specified prior releases have to finish before upgrading to GitLab 14.2. Read the GitLab 14.2 update instructions for further guidance.

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