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.

GitLab 14.2 released with the Build Cloud for macOS beta and Markdown preview via @digital_saas Click to tweet!

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 .

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 .

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!

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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:

Added support for group access tokens to authenticate with Git over HTTP, making it possible to push and pull changes with a group token.

Also provided instructions for creating group access tokens in a Rails console for your convenience.

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

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.

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:

Kubernetes PreStop lifecycle hook .

Support for Windows build pods in the Kubernetes executor .

In job output, create a section for each .gitlab-ci.yml script line when FF_SCRIPT_SECTIONS feature flag is enabled .

Allow CI image option to override base image name (VirtualBox & Parallels) .

Specified Git version upgraded to 2.30.2 .

Bug fixes:

Invalid UTF-8 results in 500 error on pipeline and job page .

Unable to clean removed sub-submodules when using GIT_STRATEGY: fetch .

Fix Ubuntu helper image builds to use correct platform (not always amd64 ) .

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

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.

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.

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.

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.

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.

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.

GoSec updated to version 2.8.1 - MR , Changelog . Please see update notice for support for 1.16 .

Security Code Scan updated to version 5.2.1 - MR , Changelog . Please see update notice for major version .

ESLint updated to version 7.32.0 - MR , Changelog .

Semgrep updated to version 0.60.0 - MR , Changelog .

If you:

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

Want to remain on a specific version of any analyzer, you can now pin to a minor version of an analyzer . 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/CD template.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

Some of the notable bug fixes in 14.2 are:

Bulk dismissal checkboxes don’t appear on group vulnerability report .

Broken layout for GraphQL vulnerability list for pipeline security tab when location names are too long .

Container scanning gives “no implicit conversion of nil into String” error when trying to offer remediation for an unexpected distribution .

Container scanning does not support public Docker registries .

Status of report comparison is not taken into account in code quality MR widget .

Login redirects for SSO flow do not redirect the user back to the originally intended page .

Delete user and contributions action is missing for users that are a sole owner of a group .

Bad request error 400 when publishing to NPM packages .

Dependency proxy does not work when SSO is enabled .

Can’t publish large NuGet packages .

Dropdown filtering groups no longer includes full path in search .

Service Desk e-mail text truncated is no longer fully discarded

Project boards show full path on cards .

The list of active labels in labels dropdown is not updated when clicking on a different card on issue boards .

Weight of epic is updated unexpectedly when child epic is expanded .

Start and due dates are incorrectly set on epic creation .

Sidebar queries do not include full path when on sub group on epic boards .

Reordering lists sending incorrect position on boards .

Using “return” to apply label on new epic creates epic without label .

Handle error on issue creation on boards .

Burndown and burnup guideline missing .

Web IDE cannot open branches containing a pipe character .

Snippets can be accessed from another project .

Remove button redirects to 404 in Slack application .

Filtering by labels is broken on Jira issues list .

DataDog integration settings can’t be reverted from Custom to Default .

Force users to reenter integration passwords instead of silently clearing them .

Diff note can possibly still not show after a file has been changed .

Can’t edit file via single file editor when MR diffs are cached .

User details can be stale when discussion is cached .

Stale cache when referenced issuable in merge request note changes its state .

Renamed files are not properly identified in MR diffs when not showing whitespace changes .

Got “Failure to squash” error when trying to merge an MR that had 1 commit .

gitlab:backup:restore does not clean tmp directory in backups directory .

Could not change to directory /root while running gitlab-ctl promote-to-primary-node in Geo .

Fix “Add to Slack” link on the GitLab Slack App .

Geo /admin/geo/nodes does not work properly with relative URLs .

Removing primary nodes in the UI not working in Geo .

Some container repositories stuck in started state in Geo .

Advanced Search should index trials on GitLab.com regardless of seat count .

Per-process Prometheus metrics for Sidekiq are missing for all but one process .

Alert note with email participants is incompatible with confidential notes in Service Desk .

“operator does not exist” error .

The banner prompting users to check their account recovery settings causes confusion .

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:

Use specialized worker when share_with_group_lock of a group is changed .

Don’t use recursive root_ancestor in linear mode .

Slow CI runners query at /api/:version/runners .

Don’t override newer versions of cached markdown in the database .

Preloading application_utilities is missing crossorigin attribute .

Query multiple group descendants at once .

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:

Prevent accidental deletion of container image repositories .

Improved error messages when Jira issue retrieval fails .

Use popovers instead of tooltips for inline code quality .

Visual review is hard to find and confused with Review App .

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.

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