14.1
Jul 22, 2021 - Sam White   Sam White

GitLab 14.1 Release

GitLab 14.1 released with Helm Chart Registry and Escalation Policies

GitLab 14.1 released with the ability to build, publish, and share Helm charts, create escalation policies to page responders, connect GitLab Runners to your Kubernetes clusters, enforce code coverage decisions, and much more!

Today, we are excited to announce the release of GitLab 14.1 with the ability to build, publish, and share Helm charts, create escalation policies to page responders, connect GitLab Runners to your Kubernetes clusters, enforce code coverage decisions, and much more!

These are just a few highlights from 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.2 release kickoff video.

Join us for GitLab Commit Virtual to learn how DevOps teams increase collaboration.

GitLab MVP badge

MVP This month's Most Valuable Person (MVP) is awarded to Andrew Smith

Andrew actively contributed numerous merge requests in the GitLab 14.1 release to help improve GitLab’s planning capabilities. He was able to make some significant improvements to GitLab’s issue and epic boards. Thanks to his work, GitLab users are now able to sort epic lists by title; view the number of open issues, weight, and progress in epic boards; and view milestone weights on milestone view lists.

In addition to contributing to the product in key ways, Andrew collaborated closely with the team as he helped identify and fix all the bugs and barriers he encountered along the way.

Thank you Andrew for helping to make GitLab better! 🙌

14.1 Key improvements released in GitLab 14.1

Build, publish, and share Helm charts

Build, publish, and share Helm charts

Helm defines a chart as a Helm package that contains all of the resource definitions necessary to run an application, tool, or service inside of a Kubernetes cluster. For organizations that create and manage their own Helm charts, it’s important to have a central repository to collect and share them.

GitLab already supports a variety of other package manager formats. Why not also support Helm? That’s what community member and MVP from the 14.0 milestone Mathieu Parent asked several months ago before breaking ground on the new GitLab Helm chart registry. The collaboration between the community and GitLab is part of our dual flywheel strategy and one of the reasons I love working at GitLab. Chapeau Mathieu!

Now you can use your GitLab project to publish and share packaged Helm charts. Simply add your project as a remote, authenticating with a personal access, deploy, or CI/CD job token. Once that’s done you can use the Helm client or GitLab CI/CD to manage your Helm charts. You can also download the charts using the API or the user interface.

What’s next? First, we’d like to present additional metadata for charts. Then we’ll start dogfooding the feature by using it as a replacement for https://charts.gitlab.io/.

So, try out the feature and let us know how it goes by commenting in the epic GitLab-#6366.

Escalation Policies

Escalation Policies

Being on-call is a stressful, 24/7 job. It’s possible to miss a notification despite your best efforts and intentions. Teams that maintain critical systems can’t afford to miss alerts for outages or service disruptions. Escalation policies are a safety net for these situations. Escalation policies contain time-boxed steps that automatically page a responder in the next escalation step if the responder in the step before didn’t respond. To protect your company from missed critical alerts, create an escalation policy in the GitLab project where you manage on-call schedules.

In GitLab 14.1, users can create, view, or delete escalation policies.

CI/CD Tunnel for Kubernetes clusters

CI/CD Tunnel for Kubernetes clusters

Until now, connecting Kubernetes clusters to GitLab CI/CD required users to open up their clusters towards GitLab. Some organizations do not encourage opening up their firewall externally due to security concerns.

GitLab now ships with a CI/CD Tunnel that connects GitLab Runners with your Kubernetes cluster using the GitLab Agent. This enables versatile GitOps workflows where the deployment logic can be coded in the pipeline.

You and your team can safely use your preferred tool to run the deployment itself using kubectl, helm, kpt, tanka, or anything else without security concerns.

To use the tunnel, define the kubecontext in your CI/CD pipeline to connect with your agent. To simplify this process, we plan to automatically inject the kubecontext into the CI/CD environment in a future iteration.

The CI/CD tunnel is currently supported only from the project where the agent was configured but we are working on adding group-level support. You can safely start using the tunnel on GitLab SaaS and self-managed instances.

Code coverage merge request approval rule

Code coverage merge request approval rule

To keep code test coverage high, you need to ensure that merge requests to your codebase never decrease test coverage. Previously, the only way to enforce this was to require approvals from users who would check for test coverage decreases as part of their reviews.

Now you can enforce this organizational policy with the new Coverage check approval rule. This is a simple way to ensure merge requests that would decrease test coverage cannot be merged.

Code coverage merge request approval rule

Datadog CI Visibility integration

Datadog CI Visibility integration

The integration with Datadog Continuous Integration Visibility provides detailed breakdowns of your GitLab pipelines, unit tests, and integration tests. View high-level metrics over time: execution statuses, durations, percentiles (p50 and p95), failure rates, queue times, and more. Datadog dashboards help you sift through your GitLab CI/CD data to identify problematic jobs that cause pipelines to fail most often.

Datadog CI Visibility integration

Create tables and upload images in the Wiki Content Editor

Create tables and upload images in the Wiki Content Editor

We began improving your wiki editing experience in GitLab 14.0, when we introduced the MVC of a new WYSIWYG Markdown editor. It supported the most common Markdown formatting options, but with some notable gaps. GitLab 14.1 continues to improve your editing experience for images and tables. You can now upload images directly into the editor. You can also insert and edit tables, including copying and pasting content from popular spreadsheet applications to bring tables from other sources into your wiki. ​

Create tables and upload images in the Wiki Content Editor

Select project access token role

Select project access token role

Users can now specify the level of access that a project token should have on the project level upon creation and can view existing project access token roles.

Prior to this release, project access tokens had the Maintainer role. For some users, this role included elevated permissions that were not required.

To avoid abuse, this feature is available for all users except for free GitLab SaaS accounts. All self-managed users as well as Premium and Gold SaaS customers can now easily select and view the appropriate role for their project access tokens.

Select project access token role

External status checks for merge requests

External status checks for merge requests

You can now contact an external API to perform a status check in a merge request. This is a great way to integrate GitLab with third-party systems that:

  • Run in an external system and do not have specific pipeline jobs.
  • Require manual approval in another system.

In the project, APIs for the status checks can be configured (using either the GitLab UI or the GitLab API) and then when a change is made to a merge request, that API is called with various details about the merge request. The external API can then respond with a return code to indicate if the check has passed. This result is then shown in the merge request.

This allows teams to easily stay in sync and makes it easy to see that merge requests have met external requirements before being merged, adding an extra method to ensure compliance requirements are met.

External status checks for merge requests

Quick access to compliance report entries

Quick access to compliance report entries

We have introduced a new quick access view to the Compliance Dashboard for you to review merge requests. Clicking on a merge request in the list will open the view. This makes it easy to quickly see the status and the details of merge requests, directly inside the Compliance Dashboard.

This helps save time by showing information about each merge request, such as the author, title, approvers, commenters, and more. You no longer have to open each merge request individually to see that information. Compliance teams can quickly review the full list of merge requests and find the ones that need attention, rather than spending time reviewing ones that do not.

Quick access to compliance report entries

Require a Jira issue to be linked to an MR

Require a Jira issue to be linked to an MR

You can now require that all merge requests in a project have an associated Jira issue created. This is a great way to ensure that code changes in GitLab are reflected in Jira issues and that teams can better stay in sync.

Require a Jira issue to be linked to an MR

DAST UI configuration experience

DAST UI configuration experience

GitLab’s Dynamic Application Security Testing (DAST) now supports a new guided configuration experience. We believe that security is a team effort and this configuration experience makes it easier for non-CI experts to get started with GitLab DAST. The tool helps a user create a merge request to enable DAST scanning while leveraging best configuration practices like using the GitLab-managed DAST.gitlab-ci.yml template and properly overriding template settings.

With GitLab DAST, users often create multiple configurations to cover different areas of their application. The new DAST configuration UI lets users create DAST site and scanner profiles. Those profiles can then be referenced in CI/CD pipeline jobs. The configuration is stored in the database and is referenced at scan runtime to load the configuration variables into the job. The only required YAML configuration is specifying the names of the site and scanner profiles that you want to use in your scan. This makes it incredibly simple to switch out configurations when your application requires. Building YAML config files for DAST from scratch is no longer necessary for your DAST jobs. We can build them for you.

DAST UI configuration experience

Inline code quality notices on MR diffs

Inline code quality notices on MR diffs

If you’re a developer authoring or reviewing a merge request, you want to know how every change impacts the quality of a project. To do this within GitLab, you previously needed two windows open:

  1. On the code diff of the merge request.
  2. On the main merge request page to see the code quality changes.

This back-and-forth is inefficient, and makes it easy to miss critical code quality issues.

The merge request Changes tab now shows you which line introduced a code quality violation, and its severity, so you can quickly identify the most critical issues to resolve. Hovering over the icon provides details about the violation.

Inline code quality notices on MR diffs

14.1 Other improvements in GitLab 14.1

Audit events for API-created GPG and SSH keys

Audit events for API-created GPG and SSH keys

Audit events are now created if a GPG key or SSH key is created using the API. This extends visibility beyond users that create keys using the GitLab UI to help you understand and secure all the ways GitLab could be accessed.

Audit events for project compliance frameworks changes

Audit events for project compliance frameworks changes

Audit events are now being created when the compliance framework for a project is changed. This provides greater visibility into potential abuse of policy controls of your projects.

Group Migration now includes Epics

Group Migration now includes Epics

The new GitLab Group Migration feature now includes Epics with all the relevant information, such as labels, comments, events, and award emojis. Existing users are matched and assigned to the Epics. The addition of Epics is a significant step in delivering a better alternative to the file-based Group Export/Import feature.

Log the number of objects imported from GitHub

Log the number of objects imported from GitHub

When you import from GitHub, the logs now contain the counts of all imported objects. This information helps users validate their imported data and troubleshoot any import issues.

Track progress on overall DevOps adoption

Track progress on overall DevOps adoption

See the total number of key DevOps features adopted across your organization using the new progress bars in DevOps Adoption. Progress bars help you understand the value that teams are getting from GitLab and evaluate the state of your DevOps transformation.

Track progress on overall DevOps adoption

User setting to display absolute times

User setting to display absolute times

GitLab displays relative times (for example, 30 minutes ago) in a lot of places. You can now change your user profile preferences to display absolute times instead, for example, ‘May 18, 2021, 3:57 PM’.

Absolute times respect your browser settings and format dates and times based on your preferred locales, for example, British English over US English. This new display option gives more information at a glance for users that need it for workflows like correlating actions in GitLab to external systems.

User setting to display absolute times

Comments indicator for merge request reviews in VS Code

Comments indicator for merge request reviews in VS Code

When responding to feedback on a merge request in Visual Studio Code, it wasn’t easy to know which files had comments. You had to open each file and search for comments.

With GitLab Workflow v3.24.0 for VS Code, we now indicate which files have comments in the merge request. This helps you easily identify the files you may need to review, to address their comments.

Comments indicator for merge request reviews in VS Code

Default branch name redirect

Default branch name redirect

As part of the larger effort to rename Git’s default initial branch in a GitLab project from master to main, we are adding an automatic redirect to streamline the transition. Previously, when projects renamed the default branch, current URLs would result in 404 Not Found. This is a frustrating experience when you are trying to navigate between branches. Now, if you navigate to a file or directory path whose default branch was renamed, you will be redirected to the updated path automatically.

Linking directly to a single, highlighted line of code or text supports collaboration on a single line, but discussions often address multiple lines of code or text. Some code editor plugins, such as GitLink for JetBrains IDEs, generate an anchor link from a selected range over multiple lines. Previously, you couldn’t use such links in GitLab repositories, because GitLab and GitHub have incompatible formats for anchor links highlighting multiple lines. Previously, only manually modifying the incompatible URL in GitLab enabled highlighting multiple lines. GitLab now supports both GitLab and GitHub formats for code highlight anchor links that cover multiple lines.

Access the CI/CD template library from the pipeline editor

Access the CI/CD template library from the pipeline editor

Templates provide an easy way for you to get familiar with GitLab CI/CD. We have a large number of templates, but accessing them isn’t intuitive. In this release we’ve added a way for you to navigate directly to the template library from the pipeline editor. This makes it easy to browse through the different templates GitLab has available, so you can more easily copy and paste the relevant sections directly into your pipeline configuration.

GitLab Runner 14.1

GitLab Runner 14.1

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

Runner registration tokens in the Admin Area are masked

Runner registration tokens in the Admin Area are masked

The instance-level runner registration token is sensitive information. If someone were to “shoulder surf” a GitLab administrator, they could copy the instance-level registration token and use it to add unauthorized runners and read secrets from the GitLab instance when runners process jobs. We have masked the token so it is only left visible on the screen when intended.

Runner registration tokens in the Admin Area are masked

Visibility into CI minute tracking and quotas for public projects

Visibility into CI minute tracking and quotas for public projects

It was really challenging to get a complete picture of your CI minute consumption because public projects were excluded from quotas. As a result, we have improved the pipeline usage page to show public project CI minute consumption. Including public projects in the CI minute quota enables you to get a complete picture of your usage to make informed decisions about your pipeline efficiency. These quotas are also supporting our efforts to curtail crypto-mining abuse.

Additionally, we are starting to implement quotas for the use of our public shared runners by pipelines in public projects. Initially, quotas for public projects will apply to all new namespaces created after July 17th. All plans will have a quota, and for new users on the Free plan, public projects will have 50,000 minutes of shared runner use available for their jobs.

The Package Registry now supports NuGet symbol packages

The Package Registry now supports NuGet symbol packages

You can use the GitLab Package Registry to publish and install NuGet packages right alongside your source code and pipelines. Since packages are collections of code, sometimes they have bugs. So how do you debug NuGet? One common way is to use debug symbols that provide information like the association between compiled and source code, names of local variables, stack traces, and more.

The problem is that although GitLab supports NuGet packages, until recently symbol packages (.snupkg) weren’t supported. This made it more difficult to share these important debugging packages with the rest of your team and prevented you from relying on GitLab as the single source of truth for your NuGet packages.

GitLab now supports publishing and installing symbol packages. To publish a symbol package, simply run nuget push My.Package.snupkg -Source <source_name>. Then you can download the .snupkg files by using the API or the user interface.

Fix create/edit/delete release permissions to match tag creation permissions

Fix create/edit/delete release permissions to match tag creation permissions

In GitLab 14.1, we are fixing the create/edit/delete release permissions to match tag creation permissions so that users have a consistent experience. This bug fix is highlighted individually because for projects that have releases associated with a protected tag, the user must have write access to both releases and protected tags in order to access the release. If this bug fix affects you, add the pertinent user to the Allowed to create list in the protected tag setting.

Vault integration with environment variables support

Vault integration with environment variables support

Vault users can easily retrieve secrets from within GitLab CI/CD by using the GitLab Vault integration. The integration initially created file type secret variables, and this approach had a few shortcomings. To overcome these we are introducing a new boolean file keyword where you can specify if the returned variable should be stored as a plain environment variable or a file.

This feature requires a GitLab Runner version 14.1.0. For backward compatibility, the default is to store the variables as file types (file: true).

Omnibus improvements

Omnibus improvements

  • GitLab 14.1 includes Mattermost 5.36, an open source Slack-alternative whose newest release includes the addition of Hungarian language support, a Focalboard project management integration (beta), and more. This version also includes security updates and upgrading from earlier versions is recommended.
  • GitLab 14.1 also introduces the ability to opt-in to PostgreSQL 13 for fresh single-node installations not using Geo or a multi-node setup. This prompt allows users to benefit from the features and functions associated with the latest version of PostgreSQL.
  • GitLab users expressed a need for more modern practices related to NGINX TLS configuration in GitLab instances. In 14.1, the SSL configuration is updated to use the intermediate setting from Mozilla’s SSL configurator.

Beta release of DAST API Security scanner

Beta release of DAST API Security scanner

In 2020, GitLab acquired Peach Tech and gained an incredibly powerful DAST API Security tool in the process. After initially focusing on the fuzz testing capabilities of the tools we acquired, we are proud to announce that the API Security scanner for DAST is now ready for use as a beta feature. This scanner immediately gives the benefit of enabling more API specification methods, more API language support, and additional authentication methods. In addition to the already supported OpenAPI specification, you can now use Postman collections and HAR files to provide multiple options for defining what can be tested in the API. In addition to supporting REST APIs, the new beta API Security scanner also supports SOAP and GraphQL API endpoints. Additional authentication methods include static cookies, form bodies, JSON bodies, and XML bodies. Dynamic headers, cookies, query strings, form bodies, JSON bodies, and XML bodies are also now supported via user-provided scripts that update the values.

As a part of this beta, the DAST API job for the API Security scanner is now separate from the traditional web application DAST job in your CI/CD pipeline. The DAST API job can be configured separately, using new variables and a new DAST API YAML template. This is a major improvement that enables usage of both web application DAST and API DAST in the same pipeline. You no longer have to choose between one type of DAST scan or the other when testing your applications. One pipeline can provide dynamic application security test coverage of both the UI and API of an application.

While this new scanner gives us a major improvement in functionality, we have identified that there are multiple vulnerability checks that need to be implemented in order to provide vulnerability coverage parity with the current DAST API scanner. We will continue to work on building those vulnerability checks to get the API Security scanner to a GA maturity. During the beta period, we strongly encourage usage of the new scanner and welcome any feedback.

Configuration tool for Secret Detection available to all

Configuration tool for Secret Detection available to all

Following in the footsteps of the GitLab SAST configuration tool we added support for Secret Detection on the Security Configuration page in 13.12. We believe that security is a team effort and this configuration experience makes it easier for non-CI experts to get started with GitLab Secret Detection which is why we’re making this tool available for all SaaS users in 14.1, and all self-managed users soon. The tool helps a user create a merge request to enable Secret Detection scanning while leveraging best configuration practices like using the GitLab-managed SAST.gitlab-ci.yml template. The Configuration tool can create a new .gitlab-ci.yml file if one does not exist or update existing simple GitLab CI files, allowing the tool to be used with projects that already have GitLab CI set up.

Configuration tool for Secret Detection available to all

Enable Dependency Scanning within the UI

Enable Dependency Scanning within the UI

Users with access to the Security Configuration page who do not yet have Dependency Scanning enabled can now enable it by clicking “Configure via Merge Request”. This will create and/or update your pipeline YAML file to add the default Dependency Scanning template. This will make it easier for you to quickly add Dependency Scanning into your project providing an additional layer of security to your standard development workflow.

Support for UBI-Based Container Scanning Image

Support for UBI-Based Container Scanning Image

GitLab now supports a Universal Baseline Image (UBI) version of the container scanning image. By default, GitLab container scanning runs on an Alpine-based image. However, you may prefer or require it to run on a UBI-based image instead. You can now choose to have your container scanning jobs run on a UBI-based image by following these steps.

Audit events for new instance administrators

Audit events for new instance administrators

Audit events are now created if a user is added as an administrator for the GitLab instance. This helps ensure that if anyone becomes an administrator (meaning they make changes to instances), there is a record of their permissions being elevated that can be audited later.

Email notification when users are deactivated

Email notification when users are deactivated

Users now receive a notification when they are deactivated. This informs users so they can:

  • Take action to reactivate their account.
  • Understand why they are no longer receiving any notifications from GitLab.
  • Understand why they can’t access GitLab APIs and repositories.

LDAP synchronization warning before external users lose access

LDAP synchronization warning before external users lose access

Users are now shown a warning if they choose to synchronize their groups with LDAP. Once groups are synchronized with LDAP, all users that are external to the LDAP group lose their access. This ensures that the user is aware of the impact of synchronization and gets a confirmation before the synchronization takes place.

LDAP synchronization warning before external users lose access

Pronouns viewable in user profile snapshot

Pronouns viewable in user profile snapshot

You can now see pronouns on the snapshot view of a user profile when you hover over someone’s name on an issue or merge request. This helps users better respond to comments using the correct pronouns without needing to navigate to the user’s profile.

Pronouns viewable in user profile snapshot

Track use of security scanning across multiple teams

Track use of security scanning across multiple teams

Track which groups across your organization have enabled SAST and DAST scanning. This is helpful for verifying compliance with organizational requirements, responding to audit requests, and tracking progress on company initiatives to make applications more secure. To track adoption, go to the Sec tab in DevOps Adoption either at the group level or instance level.

To see groups that have enabled fuzz testing and dependency scanning, use the DevOps API. Fuzz testing and dependency scanning will be added to the DevOps Adoption UI in an upcoming release.

Track use of security scanning across multiple teams

Check out branches of merge requests in Visual Studio Code

Check out branches of merge requests in Visual Studio Code

When reviewing a merge request (MR) in Visual Studio Code it can be helpful to check out the branch proposing the changes. Finding the source branch’s name and then switching context to check it out can be challenging.

Now when reviewing an MR with GitLab Workflow for Visual Studio Code you can right click the MR title to check out its source branch. This makes it easier to review the proposed changes in the larger context, test items locally, and perform other actions on the source branch.

Check out branches of merge requests in Visual Studio Code

Create and apply patches in VS Code

Create and apply patches in VS Code

When reviewing a merge request (MR) it can be helpful to make suggestions to many of the changed files. This is often done by creating a patch file with the suggestions and sharing it with others. The problem is that this requires several manual steps like running Git commands and uploading the patch file somewhere others can download it.

With GitLab Workflow v3.26.0 for VS Code you can now create and apply patches directly in your editor. The new GitLab: Create snippet patch command creates a patch with the changes in your editor and uploads that patch as a GitLab snippet.

Anyone can search for patches in the project’s snippets and apply them directly in VS Code with the GitLab: Apply snippet patch command. The applied changes can then be committed to the MR.

Sharing and collaborating around patches is a great way to propose more complex suggestions and provide clear improvements. Patches created in VS Code can also be linked to others through snippets and downloaded and applied outside of VS Code for users with different editing tools.

Display CSV files in readable table view

Display CSV files in readable table view

Data in CSV (comma-separated value) files is easier to understand when shown as a table with columns and rows, especially if the file is large. Previously, CSV information was presented as raw text in GitLab repositories. CSVs are now represented as a table, with the RAW view representing the actual comma separated values.

New content types in the Wiki Content Editor

New content types in the Wiki Content Editor

In GitLab 14.0, we introduced the Content Editor in the Wiki, a new WYSIWYG Markdown editor with support for basic content types like bold, italic, code, block quotes, and links. In 14.1, we’re adding the ability to format text with strikethrough and insert horizontal rules. Adding these frequently-used content types brings us closer to our goal of giving all users a rich editing experience without learning Markdown, with full support for the GitLab Flavored Markdown specification, to make this the default editing experience for the Wiki.

Enable GraphQL Runner API by default

Enable GraphQL Runner API by default

Previously, to manage runners programmatically, you had to fetch and manipulate data by using a REST API. As part of our plans to improve the administration of runners, we are implementing GraphQL as one foundational element in delivering a better user experience in the runner’s Admin Area UI. With this release, you can now use GraphQL queries and mutations to administer runners for your GitLab instance programmatically.

Enable GraphQL Runner API by default

Limit runner registration for groups and projects

Limit runner registration for groups and projects

Today, you can register runners at the group and project levels in a GitLab instance by default. For some organizations with more stringent security controls, administrators need to limit the registration of project and group runners. This community contribution adds two configuration options in the Admin Area so that you can turn off the runner registration options at the project and group level. To test this feature, you will need to enable the :runner_registration_control feature flag.

Thanks to Thomas Watts for their contribution!

Limit runner registration for groups and projects

Updates to Admin Area’s Runners page

Updates to Admin Area’s Runners page

Today, you can administer all runners in a GitLab instance from the Admin Area’s Runners page. However, the capabilities on this page are not helpful for GitLab administrators who are managing and operating a large fleet of runners. In this first of many planned iterations, the Admin Area’s Runners page now uses Vue.js and GraphQL. In this release, you will notice that the list and detail views are now consistent with other areas of the GitLab UI. This new architecture enables us to have a more interactive UI, iterate more quickly, and add new features and capabilities to help you administer and operate runners at scale.

Updates to Admin Area's Runners page

Work from branches in the Pipeline Editor

Work from branches in the Pipeline Editor

Previously, you could only use the pipeline editor to work on your pipeline configuration in your project’s default branch. In this release, we are adding a branch selector to the pipeline editor. Now you can use the pipeline editor from any branch you’d like, which makes it much easier to test changes before implementing them on the default branch.

Work from branches in the Pipeline Editor

Disable jailing mechanism by default for GitLab Pages

Disable jailing mechanism by default for GitLab Pages

We are now disabling the jailing mechanism for GitLab Pages by default due to problems discovered when upgrading to GitLab 14.0. Jailing is no longer relevant since we stopped serving GitLab Pages directly from disk starting in 14.0. You can still re-enable jailing if you require the functionality though. In that case, please reach out to us on the Pages migration feedback issue, so that we can investigate your case.

In GitLab 13.2, we added the ability to associate issues to feature flags. In this release, we added the ability to associate feature flags with issues. An issue often has the context for the ‘why’. Allowing a user to be able to navigate from issue to feature flag, and back again will enable the user to have the complete context on what the feature flag is for.

Related feature flags in issues

GitLab chart improvements

GitLab chart improvements

  • GitLab 14.1 replaces tail/xtail in favor of GitLab Logger in Gitaly cloud native GitLab Containers. In the past, logs were less structured which made it potentially more challenging to do proper analysis. Using GitLab Logger allows better tagging of logs to improve forensic analysis.

Registration Features

Registration Features

Registration Features introduces the ability for free, self-managed users running GitLab EE to access paid features by registering with GitLab and sharing activity data via Service Ping. Features introduced here do not remove the feature from it’s paid tier, or prevent users from accessing at that tier without sharing usage data. The first feature introduced is email from GitLab, enabling instance administrators to email users within their instance.

Registration Features

Browser-based DAST authentication

Browser-based DAST authentication

As a part of our project to move to a browser-based DAST ecosystem, we have switched the DAST authentication method over to using browser-based authentication. In addition to supporting all of the existing DAST methods of authentication, this new system allows for advanced debugging by generating a report that contains screenshots and HTTP requests made during the authentication process. The report allows a user to view all the steps in the process and see what is happening if authentication fails. The new authentication method also contains quality-of-life improvements such as greater flexibility for how to select login form elements on a page, support for clicking elements to show a popup login modal, strategies for validating whether or not authentication succeeded, and direct access to the browser logs for debugging purposes.

Dependency Scanning expands support for Gradle projects

Dependency Scanning expands support for Gradle projects

You can now enable Dependency Scanning for your Java 16 Gradle projects. Set the DS_JAVA_VERSION environment variable to 16 to use this enhancement. In addition the gemnasium-gradle-plugin has been updated to support Gradle 7.0. Gradle 7.0 issue.

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

  • Flawfinder updated to version 2.0.18 - MR, Changelog.
  • Gosec updated to version 2.8.1 - MR, Changelog.
  • Semgrep updated to version 0.57.0 - MR, Changelog:
    • Set a timeout of 10s per file.
    • Fixed bugs in detection patterns.
    • New detection patterns.
  • MobSF updated to version 2.13.0 - MR, Changelog:
    • Removes support for Python 3.8 to mitigate security issue.

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

Bug fixes

Bug fixes

Some of the notable bug fixes in 14.1 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.1, we’re shipping performance improvements for issues, projects, milestones, and much more! Some improvements in GitLab 14.1 are:

Service bulletins

Service bulletins

Non-compliant container images break garbage collection

According to the Docker Image Spec and the OCI Image Spec, a manifest list should reference only manifests. We learned that it’s possible to push manifest lists that reference layers. The root cause lies with Docker’s Buildkit (directly or through Buildx) implementation of remote cache images. It has been reported upstream, but it isn’t clear if this issue will be addressed. We have short-term and long-term goals for dealing with this.

Short term, our goal is to unblock Self-Managed customers from running offline garbage collection. For now, we updated the container registry to account for this behavior.

Long term, we must ensure that the GitLab Container Registry enforces the OCI Image Spec. Allowing manifest lists with blobs to be pushed affects data integrity and consistency. However, adding validation would introduce breaking changes for GitLab.com and Self-Managed customers. We’re gathering data on the scope of the issue and will follow up with a plan in the coming months.

In the meantime, if you have any questions, please comment in the issue.

Maximum file size for job logs, defaulting to 100MB

GitLab values efficiency for all users in our wider community of contributors, so we’re always working hard to make sure the application performs at a high level with a lovable UX. In 14.2, we plan on introducing a job log file size limit, set to 100 megabytes by default. Administrators of self-managed GitLab instances can customize this to any value. All jobs that exceed this limit are dropped and marked as failed, helping prevent performance impacts or over-use of resources. This ensures that everyone using GitLab has the best possible experience.

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

GitLab 14.1 contains batched background migrations as part of our ongoing effort to address primary key event overflow risks. These background migrations have to finish before upgrading to a later version of GitLab. Read the GitLab 14.1 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