14.9
Mar 22, 2022 - Brian Rhea   Brian Rhea

GitLab 14.9 Release

GitLab 14.9 released with epic to epic linking and integrated security training

GitLab 14.9 released with epic to epic linking, integrated security training, a new Environments page design and much more!

Today, we are excited to announce the release of GitLab 14.9 with epic to epic linking, integrated security training, a new Environments page design, rule mode for scan result policies and much more!

These are just a few highlights from the 40+ 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.10 release kickoff video.

Join us for an upcoming event

GitLab MVP badge

MVP This month's Most Valuable Person (MVP) is awarded to Timo Furrer

Timo became a maintainer of the Terraform provider for GitLab in February 2022. The Terraform provider allows an automated and codified management of GitLab users, groups and projects built on top of the GitLab APIs.

Since he joined the team, he has been active in every part of the project and the community. In only the past month, he was the assignee on 24 merged pull requests in the Terraform provider project and he drove 5 releases of the provider (v3.10.0 - v3.12.0).

Moreover, as provider users missed some GitLab APIs, Timo got his first contribution accepted to the core GitLab codebase and has 9 open MRs, all improving the GitLab APIs.

Besides the development work, Timo supported other, new contributors on the Terraform provider, thus building a healthy and growing community where people are happy to contribute.

Together with Timo, we would like to say thank you to Adam Snyder too, the second most active maintainer of the Terraform provider for GitLab. Thank you Timo and Adam! 🤝

14.9 Key improvements released in GitLab 14.9

GitLab now supports linking epics using “related”, “blocking,” or “blocked” relationships. This feature enables teams to better track and manage epic dependencies across GitLab groups. Effective dependency management is a key component of reducing variability and increasing predictability in value delivery.

Link an epic to another epic

Rule mode for scan result policies

Rule mode for scan result policies

With the GitLab 14.9 release, users can now use rule mode to design and edit scan result policies without needing to edit the policy’s YAML directly. This new UI editor makes it easier for users who want to create and manage MR approval rules that are triggered when a given threshold of vulnerabilities are detected in the MR.

To get started with this new rule mode, navigate to Security & Compliance > Policies and create a new Scan Result policy.

Rule mode for scan result policies

Deployment Approval on the Environments page

Deployment Approval on the Environments page

We are excited to introduce the Deployment Approval capability in the GitLab interface. In GitLab 14.8, we introduced the ability to approve deployments via the API. Now, deployment approvers can view a pending deployment and approve or reject it conveniently directly in the Environments page. This update continues our work to enable teams to create workflows for approving software to go to production or other protected environments. With this update, we are now upgrading the feature to beta.

New design for the Environments Page

New design for the Environments Page

Previously, the Environments page enabled you to operate and understand deployments but the design hid some important information and was difficult to read. In GitLab 14.9, we made a comprehensive update to the page so that you can answer key questions about your environments and deployments. Now, you can easily see the status of the latest deployment, the status for various environments, and which commits have been deployed.

New design for the Environments Page

Project Level Time to restore service API

Project Level Time to restore service API

In this release, we added API support for Time to Restore Service. This is the 3rd of the 4 DORA Metrics. This data helps teams continuously improve in their stability metrics.

Project Level Time to restore service API

Integrated security training

Integrated security training

GitLab provides a comprehensive set of security scanning tools that can identify all manner of security issues. Scanner findings are presented in merge requests, pipelines, and in a dedicated Vulnerability Report. When available, a recommended solution is given. However, this is not possible for all findings. Presenting security findings without guidance on how to fix identified problems or explaining the problem’s potential impact can be challenging for anyone not familiar with the specific security issue identified. This increases the time and friction involved in assessing and ultimately fixing security issues — especially in developer workflows.

We’re pleased to announce the launch of our new integrated security training functionality. Two new partners are providing the training content. GitLab is already where many developers are working, so we designed a solution to provide context-aware security training options from inside the GitLab experience.

Simply enable security training for your projects, select your preferred content sources, and view the results from a security scan. In the vulnerability finding, you’ll find a direct link to the security training that most closely matches the particular security issue, and the specific language or framework in which it was detected. Now developers can spend a few quick minutes reviewing targeted, context-relevant training to address security issues as part of their normal development workflow.

Integrated security training

14.9 Other improvements in GitLab 14.9

API endpoint to delete project topics

API endpoint to delete project topics

In a previous release, we added the ability to create and manage project topics that are used to categorize projects and find similar new projects. However, we did not create a way to delete them. In this release, thanks to Timo Furrer’s contribution, we added an API endpoint to delete project topics to make topic management more neat and efficient.

Display total time scatterplot on each value stream stage

Display total time scatterplot on each value stream stage

In value stream analytics for groups, the Days to completion chart has been renamed to Total time. Instead of using the dropdown to view Total time data for a stage, you now select the stage from the top of the page.

New API endpoints for keys and tokens

New API endpoints for keys and tokens

GitLab 14.9 delivers new REST API endpoints:

  • Return a single SSH key for a specified user. This is useful to enable GitLab SSH keys to be a Terraform-managed resource.
  • Return a single project’s deploy token by ID. This allows for a simple request to return a deploy token instead of returning and sorting through pages deploy tokens with the API.
  • Return a single group access token or project access token.

Thank you Timo Furrer for your contribution!

Notifications for new PATs and email addresses

Notifications for new PATs and email addresses

Users want to be aware when new personal access tokens are created for and new email address are added to their account. In GitLab 14.9, a user’s primary email address is sent a notification when:

  • A new personal access tokens is created for their account.
  • A new email address is added to their account.

This acts as an extra layer of security and can serve as a warning of suspicious activity.

Thank you Riccardo Padovani for your contribution!

Special characters not permitted in new project names

Special characters not permitted in new project names

Project and Group names that have a leading or trailing special character breaks the container registry. As of this release, you can no longer use special characters as the first or last characters of new project or group names. You can still use special characters in any other part in the name. This ensures proper functionality within all stages at GitLab, and enhances the experience of our single platform tool.

Users can recover projects pending deletion

Users can recover projects pending deletion

In previous versions of GitLab, only Administrators could see projects that were pending deletion.

With GitLab 14.9, all users can now view the Pending deletion tab. Project and group owners can view and recover projects that were accidentally deleted and have not yet been permanently removed from disk. This means users can recover their own accidentally deleted projects without needing to direct all recovery requests to an Administrator. To see the tab, on the top bar, select Menu > Projects > Pending deletion.

Users can recover projects pending deletion

Render pasted Markdown in the wiki WYSIWYG editor

Render pasted Markdown in the wiki WYSIWYG editor

Markdown content destined for your GitLab wiki is sometimes created outside of GitLab. In the “classic” wiki editor, you can paste valid Markdown with no problem, because you are working with the raw source. The page only renders when you submit the content. In the wiki WYSIWYG editor, however, your clipboard’s content might have been pasted in as plain text, forcing you to manually reformat every line to remove Markdown syntax and re-format it using the WYSIWYG tools.

In GitLab 14.9, the Markdown content you paste into the WYSIWYG editor using Command / Control + V is parsed and rendered as rich text. You can still force the content to paste as plain text using Command / Control + Shift + V.

Artifact sizes are being recalculated

Artifact sizes are being recalculated

Because of previous statistics calculations, the total artifact sizes shown in usage quotas might be incorrect. To ensure artifacts sizes are reporting accurately, we have added a background script on GitLab.com to automatically recalculate sizes.

You may notice artifact statistics will fluctuate to 0 at times while the script is recalculating. After recalculation, statistics will return to normal.

Include the same CI/CD template multiple times

Include the same CI/CD template multiple times

Previously, trying to have standard CI/CD templates that you reuse in many places was complicated because each template could only be included in a pipeline once. We dropped this limitation in this release, so you can include the same configuration file as many times as you like. This makes your CI/CD configuration more flexible as you can define identical includes in multiple nested configurations, and rest assured that there will be no conflicts or duplication.

ARM support for the GitLab agent for Kubernetes

ARM support for the GitLab agent for Kubernetes

The GitLab agent for Kubernetes now supports ARM32 and ARM64 architecture. This is an important step to provide support for cluster connections running on Apple M1 chips or in low powered environments like the Raspberry PI.

Prior to this update, to refer to the latest release of a project, users needed to know the exact version number. We have now added a link to the latest release for a project. This makes it much easier and more efficient to navigate to the latest release.

Provision a Kubernetes cluster from GitLab with Terraform

Provision a Kubernetes cluster from GitLab with Terraform

GitLab has deep integrations with Kubernetes for deployments and security. However, some users struggle with setting up an initial cluster with GitLab. The UI-based solution for this integration had several shortcomings and the configuration options were very limited.

You can now use an example project and related documentation to help set up a Kubernetes cluster using Terraform as the Infrastructure-as-Code methodology. This solution uses the GitLab agent for Kubernetes as the component that connects GitLab to your cluster. Using this example, you can create your own project and fully customize it for your needs. The example project provisions a cluster to Amazon Elastic Kubernetes Service (EKS) or Google Kubernetes Engine (GKE).

View GitLab agent for Kubernetes version in the UI

View GitLab agent for Kubernetes version in the UI

If you use the GitLab agent for Kubernetes, you must ensure that the agentk version installed in your cluster is compatible with the GitLab version. While the compatibility between the GitLab installation and agentk versions is documented, until now it was not very intuitive to figure out compatibility issues. To support you in your upgrades, GitLab now shows the agentk version installed on the agent listing page and highlights if an agentk upgrade is recommended.

Geo accelerates static assets when using a unified URL

Geo accelerates static assets when using a unified URL

When Geo is configured to use a unified URL, secondary sites proxy requests back to the primary site when they can’t serve those requests locally.

In this release, static assets such as images are served directly by the secondary sites and are no longer proxied to the primary site. This may result in faster page load times for Geo users in remote locations.

GitLab chart improvements

GitLab chart improvements

Previously, code from archived projects was not searchable by default if Advanced Search was enabled. Now, code search for archived projects falls back to basic search. For this to work, however, you must either search within the project or first select the project from the search results page.

Code Search for archived projects that are not indexed by Advanced Search

Searching for issues across groups is now twice as fast

Searching for issues across groups is now twice as fast

It could be slow to search across groups with many projects using Advanced Search. The slowness was caused by a lookup for each project in the group. Groups with many projects would take a long time to return results. We now use inheritance, which makes these searches perform twice as fast.

Dependency Scanning outputs CycloneDX documents

Dependency Scanning outputs CycloneDX documents

In order to align with a popular Software Bill of Materials (SBOM) industry format standard, Dependency Scanning’s gemnasium analyzers will now output a CycloneDX SBOM for each supported lock or build file detected. These CycloneDX SBOMs are named cyclonedx-<package-type>-<package-manager>.json, and are saved in the same directory as the detected lock or build files. The CycloneDX SBOMs can be downloaded the same way as other job artifacts.

UI option to enable Container Scanning

UI option to enable Container Scanning

GitLab 14.9 now supports Container Scanning on the Security Configuration page. Security is a team effort and this configuration experience makes it easier for non-CI experts to get started with GitLab Container Scanning. The tool helps a user create a merge request to enable Container Scanning, while leveraging best configuration practices like using the GitLab-managed Container-Scanning.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. You can therefore use the tool with projects that already have GitLab CI set up. To get started, navigate to Security & Compliance > Configuration and visit the Container Scanning section.

UI option to enable Container Scanning

API for Security & Compliance menu visibility

API for Security & Compliance menu visibility

Previously, the Security & Compliance menu could only be enabled or disabled using the GitLab UI.

Thanks to a community contribution, GitLab now provides an API to allow users to enable or disable the Security & Compliance menu. To get started, see the API documentation.

Filter group members by provisioned users

Filter group members by provisioned users

Prior to this release, you could have a mix of provisioned and non-provisioned users in groups, but there is no way to filter by this status to easily locate them. We have now added the ability to filter by the enterprise badge which is available to group owners.

You can now filter by the Enterprise user badge, making it easy to allocate the provisioned users in groups and projects with many members.

Filter group members by provisioned users

New audit events

New audit events

The GitLab 14.9 release adds support for auditing the following activities: - Creating a new merge request approval rule. - Deleting a merge request approval rule. - Approving a merge request. (Supported as streaming audit events only.) - Creating, deleting, or revoking a project or group deploy token. - Failed attempts to create a project or group deploy token. - Authenticated git push or git pull commands to a private repository performed over either SSH or HTTPS (Supported as streaming audit events only.)

Parent-child support for compliance pipelines

Parent-child support for compliance pipelines

In GitLab 14.8 (released February 22nd, 2022), we added support for compliance pipelines to use the trigger: keyword to initiate a child pipeline. This change will help organizations who choose to organize their jobs with parent-child pipelines.

Streaming audit events for MR approvals

Streaming audit events for MR approvals

You can now monitor merge request approval activity that happens on the merge requests in your groups and projects. You can see which merge requests are being approved and by whom, if you need to refer back to that later.

Because of the volume of data we expect to be generated by these events, they are only available as streaming audit events.

When creating a new issue from another issue, an option to mark the two issues as related is selected by default. This handy shortcut enables you to create one or more related issues without having to remember or copy-pasting issue IDs.

Thanks for the contribution Steve!

Shortcut to open related issue

Review previously merged commits in merge requests

Review previously merged commits in merge requests

The best code reviews take into account the broader context and impact of changes, including previously merged commits. But it can be challenging to bring that context into merge requests, so that everyone can discuss how the proposed changes align with older changes.

You can now stack previously merged commits onto the proposed changes in your merge request, to help you and everyone else understand the full context of the changes.

Thanks to Paulo Vitor Magacho, Anwar Sadath and Abhishek Kumar for all working to contribute this!

Review previously merged commits in merge requests

GitLab Runner 14.9

GitLab Runner 14.9

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

Specify variables when running manual jobs via the API

Specify variables when running manual jobs via the API

When running a manual job, it can be useful to input CI/CD variables to overwrite the existing variables, or to add new ones. Previously, the only way to do this, was to do it through the UI. In this release we’ve added the ability to specify variables when running a job by using the REST API, which will give you more options for automating your CI/CD pipelines.

Add comment when approving/rejecting a deployment

Add comment when approving/rejecting a deployment

In this release, we have introduced an enhancement to deployment approvals. You can now leave an optional comment when reviewing a deployment, providing more context as to why the deployment was approved or rejected. This functionality is also useful for organizations in highly regulated industries that need to audit release events.

Add comment when approving/rejecting a deployment

Persistent Volumes in Auto DevOps

Persistent Volumes in Auto DevOps

Previously, when you deployed an application via Auto DevOps that requires Persistent Volumes, you had to create a custom chart repository. However, it was cumbersome to host a chart repository on your own due to the maintenance burden. In GitLab 14.9, you can create Persistent Volumes by specifying the persistence keyword in the configuration file.

Thank you Frank Brooks for your contribution!

Simplified migration to agent-based connections

Simplified migration to agent-based connections

If you have a certificate-based cluster that’s connected with GitLab, you can now use an agent-based connection at the same time. Previously, to migrate from a certificate-based connection to an agent-based setup, you had to complete additional steps, and the process was especially difficult for group and instance-level clusters. By presetting both Kubernetes contexts, migration is largely simplified. You can now select the context provided by the agent, instead of the default context that’s provided by the certificate-based connection.

During an incident, it can be challenging to capture and organize metrics. Starting in this release, users can add links and text to images of incident metrics. This makes it easier to reference metrics throughout the incident.

Geo’s admin area supports secondary-specific actions when using unified URLs

Geo’s admin area supports secondary-specific actions when using unified URLs

When Geo is configured with a unified URL, system administrators would not be able to directly access secondary site specific replication details or perform actions in Geo’s administrator area. This was only possible when using the IP address of a secondary site directly or by setting up another domain name.

In 14.9, Geo supports viewing replication details and performing actions directly in the admin area without the need for a workaround. This change excludes Projects and Designs, which will be supported in a future iteration.

Omnibus improvements

Omnibus improvements

  • GitLab 14.9 includes Mattermost 6.4, with unlimited playbooks, and multiple Boards enhancements including standard templates, template previews, new archive format with image support, card badges, and GIF support. This version also includes security updates and upgrade from earlier versions is recommended.
  • GitLab Spamcheck is now available in the Omnibus package. Spamcheck started as a GitLab internal project, however, it became clear that the community could benefit from these efforts, and the decision was made to strive towards making much of it public. Spamcheck allows users to detect, and mitigate the effects of spam.

Some of the processes in Global Search conduct up to 10 queries per search. When there is a sudden rush of searches, this can slow performance and impact other parts of GitLab. To improve the overall stability of GitLab, we have added rate limits for Global Search. These rate limits are automatically enabled and are preset to the configurations used by GitLab.com. The new search_rate_limit replaces the rate limit for user_email_lookup_limit. Consult the Important notes on upgrading to GitLab 14.9 section for details.

Dependency Scanning adds support for Java 17

Dependency Scanning adds support for Java 17

We have added support for Java 17 to Dependency Scanning. Thank you to community contributors @rpandini_wh and @gliDom for their assistance. If you are using the latest, or latest major (2), version of the container you do not need to do anything to receive this update. If you have pinned your container to a minor or specific version please update to at least 2.26.0 receive this update.

Static Analysis analyzer updates

Static Analysis analyzer updates

GitLab Static Analysis includes many security analyzers that the GitLab Static Analysis team actively manages, maintains, and updates. The following analyzer updates were published during the 14.9 release milestone. These updates bring additional coverage, bug fixes, and improvements.

  • Bandit analyzer updated to version 1.7.4. See CHANGELOG for details.
  • Brakeman analyzer updated to version 5.2.1. See CHANGELOG for details.
    • Add initial Rails 7 support
    • Fix issues with rules
    • Add checks for unsupported Ruby and Rails versions
  • ESLint analyzer updated to version 7.29.3 of eslint-plugin-react and new versions of various dependencies. See CHANGELOG for details.
    • Add, fix, and update various rules
  • Kics analyzer updated to version 1.5.3. See CHANGELOG for details.
    • Fix various rules
    • Improve IAM Policy evaluation
    • Expand coverage of privileged-container Kubernetes rule
  • MobSF analyzer updated to version 3.5.0. See CHANGELOG for details.
    • Reduce severity of some existing rules
  • PMD analyzer updated to version 6.43.0. See CHANGELOG for details.
  • Secrets analyzer updated. See CHANGELOG for details.
  • Semgrep analyzer updated to version 0.84.0. See CHANGELOG for details.
    • Improve handling of global constants and Go raw string literals
  • SpotBugs analyzer updated to version 4.6.0. See CHANGELOG for details.

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

Bug fixes, performance improvements, and UI improvements

Bug fixes, performance improvements, and UI improvements

At GitLab, we’re dedicated to providing the best possible experience for our users. With every release, we work tirelessly to fix bugs, improve performance, and enhance UI. Whether you’re one of the over 1 million users on GitLab.com or using our platform elsewhere, we’re committed to making sure your time with us is smooth and seamless.

Click the links below to see all the bug fixes, performance enhancements, and UI improvements we’ve delivered in 14.9.

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.

  • GitLab self-monitoring project
  • Integrated error tracking disabled by default
  • `user_email_lookup_limit` API field
  • htpasswd Authentication for the container registry
  • GraphQL permissions change for Package settings
  • Background upload for object storage
  • Permissions change for downloading Composer dependencies
  • 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.

    • Integrated error tracking disabled by default
    • Other notable changes Other notable changes

      Integrated error tracking disabled by default

      Integrated error tracking disabled by default

      In GitLab 14.4, GitLab released an integrated error tracking backend that replaces Sentry. This feature caused database performance issues. In GitLab 14.9, integrated error tracking is removed from GitLab.com, and turned off by default in GitLab self-managed. While we explore the future development of this feature, please consider switching to the Sentry backend by changing your error tracking to Sentry in your project settings.

      For additional background on this removal, please reference Disable Integrated Error Tracking by Default. If you have feedback please add a comment to Feedback: Removal of Integrated Error Tracking.

      Important notes on upgrading to GitLab Important notes on upgrading to GitLab 14.9


      • GitLab 14.9, renames the rate limit key, user_email_lookup_limit to search_rate_limit. This breaking change was accidentally included in a minor release of GitLab. In 14.9.0, any API calls attempting to change the rate limits for user_email_lookup_limit should use search_rate_limit instead. To address this, we are going to alias user_email_lookup_limit to search_rate_limit in the next 14.9.x patch release.

      • Reminder: GitLab 14.6 introduced a feature flag (ci_destroy_all_expired_service), which controls the service that removes expired CI/CD artifacts.

        In GitLab 14.9, we have enabled this feature flag by default, which allows the service to start removing expired artifacts again. For more information, see the relevant issue.


      Changelog Changelog

      Please check out the changelog to see all the named changes:

      Installing Installing

      If you are setting up a new GitLab installation please see the download GitLab page.

      Updating Updating

      Check out our update page.

      Questions? Questions?

      We'd love to hear your thoughts! Visit the GitLab Forum and let us know if you have questions about the release.

      GitLab Subscription Plans GitLab Subscription Plans

      • Free

        Free-forever features for individual users

      • Premium

        Enhance team productivity and coordination

      • Ultimate

        Organization wide security, compliance, and planning

      Try all GitLab features - free for 30 days

      Cover image licensed under Unsplash License

      We want to hear from you

      Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.

      Share your feedback

      Take GitLab for a spin

      See what your team could do with The DevSecOps Platform.

      Get free trial

      Have a question? We're here to help.

      Talk to an expert
      Edit this page View source