15.1

GitLab 15.1 Release

GitLab 15.1 released with SAML Group Sync and SLSA level 2 build artifact attestation

GitLab 15.1 released with SAML Group Sync, SLSA level 2 build artifact attestation, links to included CI/CD configuration, enhanced visibility into value stream with DORA metrics and much more!

Today, we are excited to announce the release of GitLab 15.1 with SAML Group Sync, SLSA level 2 build artifact attestation, links to included CI/CD configuration, enhanced visibility into value stream with DORA metrics, and much more!

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

Join us on June 23rd as we celebrate DevOps! GitLab co-founder and CEO, Sid Sijbrandij, will introduce best-selling author and DORA co-founder, Gene Kim. Gene will share his research and expectations for the future of DevOps then GitLab VP of Product, David DeSanto, will share how GitLab is evolving The One DevOps Platform to meet that future. We'll also unveil a new program to support your career aspirations. You won't want to miss this one-hour virtual event. Reserve your seat now!

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

GitLab MVP badge

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

In the 15.1 milestone, feistel has helped to reduce documentation technical debt and improve GitLab documentation. Their dedication has helped to ensure GitLab documentation is consistent, clear, and easy to follow.

In addition, feistel proactively tackled seven issues to ensure the Package stage is FIPS compliant, which ensures that GitLab is compliant with the U.S Federal Government standards.

Throughout all of this, feistel worked iteratively and collaboratively. Thank you, feistel! 🙌

15.1 Key improvements released in GitLab 15.1

SAML Group Sync for self-managed GitLab

SAML Group Sync for self-managed GitLab

You can now map a group in your identity provider to a self-managed GitLab group using SAML group links. Previously, this feature was only available for GitLab.com. Group memberships are updated when a user logs into GitLab through their SAML provider.

This new functionality decreases the workload for GitLab administrators and reduces onboarding time for group members.

SAML Group Sync for self-managed GitLab

Enhancing visibility into Value Stream with DORA metrics

Enhancing visibility into Value Stream with DORA metrics

With the addition of the four DORA metrics tiles to the Value Stream Analytics dashboard, you can now track team performance and value flow from ideation to customer delivery.

Additionally, we added a new trend chart for the DORA Time to restore service metric to provide insights into software stability and reliability trends. This new chart shows information about how long it takes an organization to recover from a failure in production.

This is the third DORA chart that’s available out of the box in GitLab. We plan to keep improving the visibility into DORA metrics and also add charts for the fourth metric: Change failure rate.

Enhancing visibility into Value Stream with DORA metrics

SLSA-2 attestation included for build artifacts

SLSA-2 attestation included for build artifacts

Supply-chain Levels for Software Artifacts (SLSA) is a security framework that helps ensure the security and integrity of your software supply chain. By default, GitLab Runner is now capable of generating and producing SLSA-2 compliant attestation metadata for build artifacts.

If the artifact is stored in a registry, then the attestation metadata is stored alongside the artifact in that registry. Otherwise, the metadata is in rendered in a plain text .json file that’s stored with the artifact.

This new attestation information can help you more easily verify that your build artifacts have not been tampered with. To enable this feature, simply set RUNNER_GENERATE_ARTIFACTS_METADATA = "true" in your .gitlab-ci.yml file.

A typical CI/CD configuration uses the include keyword to import configuration stored in other files or CI/CD templates. When editing or troubleshooting your configuration though, it can be difficult to understand how all the configuration works together because the included configuration is not visible in your .gitlab-ci-yml, you only see the include entry.

In this release, we added links to all included configuration files and templates to the pipeline editor. Now you can easily access and view all the CI/CD configuration your pipeline uses, making it much easier to manage large and complex pipelines.

15.1 Other improvements in GitLab 15.1

API includes additional detail about who added members

API includes additional detail about who added members

The members API now returns more information about who added a user to a project or group in the new created_by field.

Thank you Rémy Jacquin for your contribution!

Improved insights discovery in Value Stream Analytics

Improved insights discovery in Value Stream Analytics

We’ve made several enhancements to how you view data for each stage of the Value Stream Analytics dashboard. In the stage table, we added the Last event column to show the most recent workflow event, and you can now sort items by duration.

These changes make it easier for you to rearrange the events and discover insights faster. These insights could be in detecting bottlenecks that are slowing down delivery, or finding opportunities to reduce the time spent on each stage of the software supply chain.

Improved insights discovery in Value Stream Analytics

Retrieve PAT by ID using API

Retrieve PAT by ID using API

Users can now retrieve their personal access tokens (PATs) by the PAT ID. Previously, users could only list all their personal access tokens using the API. There was no endpoint to support querying them one by one.

Thanks to Andreas Deicha for their contribution!

GitLab.com sign-in for GitLab Workflow for VS Code

GitLab.com sign-in for GitLab Workflow for VS Code

Getting started with GitLab Workflow for VS Code has been challenging: install the extension, only to learn you needed to follow several extra steps to set the extension up properly. The most difficult aspect of getting started was generating a personal access token with the right scope and adding it to the extension.

Release v3.47.0 of GitLab Workflow now supports OAuth for GitLab.com, removing the need to manually generate a token. This is a huge step in making it easier for you to start using GitLab inside of VS Code.

GitLab Runner 15.1

GitLab Runner 15.1

We’re also releasing GitLab Runner 15.1 today! GitLab Runner is the lightweight, highly-scalable agent that runs your CI/CD 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:

View shared runner usage per project in a group

View shared runner usage per project in a group

Using shared SaaS runners for public projects have the same CI/CD minutes limits as the corresponding tier the project is on. Users managing groups could see the total runner usage for the entire group, but could not see the usage for individual projects in one place. This made it hard to identify which projects within a group were using the most CI/CD minutes.

Now you can see the SaaS runner usage for the group by project, the same as you can in a personal namespace. It is now easier to find the projects that are using the most CI/CD minutes and, if necessary, make their pipelines more efficient.

View shared runner usage per project in a group

Agent server for Kubernetes enabled by default in the Helm chart

Agent server for Kubernetes enabled by default in the Helm chart

The first step for using the agent for Kubernetes in self-managed instances is to enable the agent server, a backend service for the agent for Kubernetes. In GitLab 14.8, we enabled the agent server for Omnibus based installations.

The feature has matured in the past few months, so we are now making the agent server enabled by default in the GitLab Helm chart as well to simplify setup for GitLab administrators. Besides being enabled by default, the agent server accepts various configuration options to customize it according to your needs.

Create annotated Tags with the GraphQL Release API

Create annotated Tags with the GraphQL Release API

Previously, you were only able to create lightweight tags when using the GraphQL API to create a release. With this update, you can now add an optional tagMessage parameter to create an annotated tag when creating a release. This enables you to include relevant information along with the new tag, so downstream users and applications can have additional context.

Deploy keys by user API

Deploy keys by user API

Previously, to enable deploy keys for a group of projects, administrator access was required to retrieve the id of the deploy key. This release adds a new API endpoint (GET /users/:id_or_username/project_deploy_keys) to retrieve all the keys accessible by a given user, so you can complete this task without waiting for an administrator. In a future iteration, the API will also include public deploy keys.

GitLab agent for Kubernetes supports proxied connections

GitLab agent for Kubernetes supports proxied connections

Many users require a proxy to connect Kubernetes clusters to GitLab. Previously, the default installation method for the GitLab agent for Kubernetes did not support proxied connections. Now, you can use the HTTP_PROXY environment variable in the agentk Helm package to support proxied connections.

FIPS-enabled Red Hat UBI Dependency Scanning image

FIPS-enabled Red Hat UBI Dependency Scanning image

Dependency Scanning for Java (gemnasium-maven) is now available on a FIPS-enabled Red Hat UBI image. When FIPS mode is enabled, this image uses the OpenJDK packages for RedHat UBI 8 instead of the non-FIPS-compliant asdf-java package that is used by default. When FIPS mode is enabled, only Java versions 7, 11, and 17 are supported.

To begin scanning using the FIPS-compliant Dependency Scanning image, simply include the Dependency Scanning template in your CI/CD file and set the DS_IMAGE_SUFFIX variable to "-fips".

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

  • Kics analyzer updated to version 1.5.0. See CHANGELOG for details.
    • Add 82 new queries (rules) for Ansible, CloudFormation, Docker Compose, Kubernetes, and Terraform
    • Fix/update existing queries
    • Fix bugs in scanning and analysis
    • Improve performance
  • Secret Detection analyzer updated for better offline support and easier debugging. See CHANGELOG for details.
    • Improve logging
    • Use checked-out copy of the repository if git fetch fails
    • Fall back to scanning the latest commit if automatic diff detection fails
  • Security Code Scan analyzer updated to improve logging. See CHANGELOG for details.
  • Semgrep analyzer updated to use the latest version of GitLab-managed rulesets. See CHANGELOG for details.
    • Remove incorrect mapping to Gosec rule ID G104
    • Add rule G402 to detect use of TLS versions before 1.2
  • SpotBugs analyzer updated to SpotBugs version 4.7.0 and find-sec-bugs version 1.12.0. See CHANGELOG for details.
    • Update gradle and grails to support Java 17
    • Set Java 17 as the system-wide default version
    • Use ‘assemble’ task for Gradle projects, instead of ‘build’, to support custom GRADLE_CLI_OPTS (see issue #299872)
    • Add additional detection rules

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.

For previous changes, see last month’s updates.

Geo links directly to the replication views on the secondary site for each data type from the primary site’s admin dashboard. It is now possible to drill down to the list of individual objects for each data type on a secondary using the clickable links on the primary site’s admin dashboard.

This will help troubleshoot replication and verification issues at secondary sites, allowing system administrators to trigger resync and re-verify any objects failing to sync. It also improves overall observability of the replication and verification process by showing details of progress with information such as next sync attempt, last successful sync, and verification times for each object.

Geo supports OCI container images

Geo supports OCI container images

With GitLab 15.1, Geo supports replication of OCI container image format. OCI container images have been growing in popularity, and you are now able to replicate those images across Geo sites, similar to Docker manifest V1 and V2 images.

Omnibus improvements

Omnibus improvements

  • GitLab 15.1 includes Mattermost 6.7, whose newest release includes Playbooks task due dates and more! This version also includes security updates and upgrade from earlier versions is recommended.
  • Debian 9 (stretch) will reach end of life for long term support in June 2022. Therefore, we will stop building packages for Debian 9 (stretch) in GitLab 15.1.

Previously, GitLab.com group maintainers had to ensure they created group links for all users that would sign in using SAML. Otherwise, users that aren’t in any linked groups could authenticate successfully but would immediately have their access and SAML identity removed.

Now, instead of being removed, those GitLab.com users are automatically assigned the default role. This alleviates the burden from the group maintainer to have to make sure there is a group link for every user.

Prevent users from using known insecure public keys

Prevent users from using known insecure public keys

When you attempt to add a new SSH key to your GitLab account, the key is checked against a list of SSH keys that are known to be compromised. Users can’t add keys from this list to any GitLab account. This helps to secure your GitLab instance.

Thank you hackercat for your contribution!

Prevent users from using known insecure public keys

Block Git access protocols at group level

Block Git access protocols at group level

To improve security, you can now block Git access protocols that you don’t use at the group level. This is similar to the GitLab administrator setting, but can now be set per group. By default, both HTTP(S) and SSH are enabled. In your group’s Settings > General > Permissions, scroll to Enable git access protocols and remove any protocols you don’t use.

Block Git access protocols at group level

Rendered images in Python notebook MRs

Rendered images in Python notebook MRs

Python notebooks are key to data scientists’ and machine learning engineers’ workflows. These files commonly display charts and graphs via static images to help visualize the notebook.

With this release, we now render these images in the merge request and commit view enabling a better user experience when reviewing code changes including Python notebooks with images.

Rendered images in Python notebook MRs

Retry a downstream pipeline from the pipeline graph

Retry a downstream pipeline from the pipeline graph

Previously, to retry a downstream pipeline, you had to navigate to the pipeline and select retry. This worked, but was a challenging experience when there were multiple downstream pipelines. You had to go into every individual pipeline you wanted to retry and find the retry option, which was cumbersome.

In this release, we’ve improved the user experience by adding an option to retry downstream pipelines directly from the pipeline graph, without the need to go into each pipeline’s details page.

Retry a downstream pipeline from the pipeline graph

View your runners’ upgrade status

View your runners’ upgrade status

As the number of installed runners in your organization increases to hundreds or thousands, it becomes more challenging to determine which runners are outdated. Failing to update the version of GitLab Runner that your runners are using doesn’t just mean you aren’t using the latest features–it could also mean that you aren’t taking advantage of security fixes.

In the Admin Area, you can now identify at a glance which runners in your environment are outdated. Badges indicate whether an upgrade is recommended (for patches) and or an upgrade is available (for a minor or major upgrade). This feature makes it easier to maintain your runner fleet and mitigate the risks of using outdated versions.

View your runners' upgrade status

Previously, the Release links API only accepted a personal access token or a project access token for authentication. With this update, a CI_JOB_TOKEN is now accepted for authentication to use with the API to manipulate GitLab Release links.

Thank you Timo Furrer for your awesome contribution!

Create annotated tags with the Releases API

Create annotated tags with the Releases API

Previously, you were only able to create lightweight tags when using the Releases API to create a release. With this update, you can now add an optional tag_message parameter to create an annotated tag when creating a release. This enables you to include relevant information along with the new tag, so downstream users and applications can have additional context.

Force stop an environment

Force stop an environment

In 15.1, we added a force option to the stop environment API call. This allows you to delete an active environment without running the specified on_stop jobs in cases where running these defined actions is not desired.

More kubectl calls for the agent CI/CD workflow

More kubectl calls for the agent CI/CD workflow

If you use the GitLab agent for Kubernetes with GitLab CI/CD, previously you couldn’t use kubectl exec, attach, cp, or port-forward calls. GitLab now supports these calls on top of the SPDY protocol. If your load balancer or reverse proxy supports SPDY, you can now use kubectl exec, attach, cp, or port-forward in your CI jobs. Both the Helm Chart and Linux (Omnibus) installations of GitLab use NGINX and are configured to support SPDY out of the box.

Unfortunately, some cloud providers do not support SPDY. GitLab is working with the Kubernetes community to ship Websockets support in Kubernetes, which will be the solution for many cloud-hosted GitLab instances, including GitLab SaaS.

Optionally ignore scanning NPM development dependencies

Optionally ignore scanning NPM development dependencies

GitLab’s Dependency Scanner analyzes vulnerabilities in application libraries that are used in a project, regardless of whether those libraries are regular dependencies or development dependencies. Some users would like to focus only on regular dependencies, ignoring any vulnerabilities found in the development dependencies.

Excluding these development dependencies from scanning is now possible for NPM projects by setting the DS_INCLUDE_DEV_DEPENDENCIES variable to "false". Open issues to extend this support to future package managers can be tracked in this epic.

Container Scanning analyzer updates

Container Scanning analyzer updates

GitLab Container Scanning supports both the Trivy and Grype analyzers. The following analyzer updates were published during this release milestone:

  • Trivy analyzer updated to version 0.28.1.
  • Grype analyzer updated to version 0.38.0.
  • Added support for detecting vulnerabilities in .NET packages when the CS_DISABLE_LANGUAGE_VULNERABILITY_SCAN: "false" variable is set.

These updates bring additional coverage, bug fixes, and improvements.

Geo proxying support for site-specific URLs

Geo proxying support for site-specific URLs

In GitLab 14.6, Geo allowed secondary sites to transparently proxy write requests to the primary site while accelerating most read requests. Until now, this feature required configuring a unified URL.

In GitLab 15.1, Geo’s proxying feature for the web UI works by default with secondary site-specific URLs. Customers who prefer maintaining different URLs for sites can now take advantage of a complete web UI experience.

Native Geo support for Object Storage replication is Generally Available

Native Geo support for Object Storage replication is Generally Available

After extensive testing and fixing a few outstanding issues, native Geo support for object storage replication is now generally available. Geo now natively supports replicating data in object storage such as LFS objects, job artifacts, and uploads. Previously, Geo could be configured to work with object storage, however the replication of the content was always left to the object storage provider. This imposed limitations when users relied on local storage appliances that do not support any replication logic.

You can use Geo to replicate your data across different object storage providers in different regions (for example Amazon in Europe and Microsoft in the United States), as well as use local storage (for example through MinIO) and use Geo to replicate data to secondary sites.

Verification of data will be added in a later iteration.

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

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.

  • `projectFingerprint` GraphQL field
  • `name` field for `PipelineSecurityReportFinding` GraphQL type
  • Jira DVCS connector for Jira Cloud
  • 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.

    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