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

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!

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.

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.

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.

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.

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.

New GitLab Kubernetes Agent UI

The GitLab Kubernetes Agent 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.

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.

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.

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.

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.

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.