15.3

GitLab 15.3 Release

GitLab 15.3 released with tasks for managing your work and free GitOps features

GitLab 15.3 released with tasks in issues, free GitOps features, SAML group link API maintenance, advanced password complexity requirements, and much more!

Today, we are excited to announce the release of GitLab 15.3 with tasks in issues, free GitOps features, SAML group link API maintenance, advanced password complexity requirements, and much more!

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

We thank the wider GitLab community for the 348 contributions they provided to GitLab 15.3! At GitLab, everyone can contribute and we couldn't have done it without you!

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

GitLab MVP badge

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

This month we recognize Marco Zille, who has provided consistent contributions to GitLab, as our MVP!

Marco has been contributing a series of UI polish improvements across GitLab 15.2 and GitLab 15.3, as well as iteratively building out the Time tracking feature in collaboration with others.

Finally, Marco contributed the ability to link directly to markdown source files.

Fantastic work! Thank you, Marco.

15.3 Key improvements released in GitLab 15.3

Create tasks in issues

Create tasks in issues

Tasks provide a robust way to refine an issue into smaller, discrete work units. Previously in GitLab, you could break down an issue into smaller parts using markdown checklists within the description. However, these checklist items could not be easily assigned, labeled, or managed anywhere outside of the description field.

You can now create tasks within issues from the Child Items widget. Then, you can open the task directly within the issue to quickly update the title, set the weight, or add a description. Tasks break down work within projects for GitLab Free and increase the planning hierarchy for our GitLab Premium customers to three levels (epic, issue, and task). In our next iteration, you will be able to add labels, milestones, and iterations to each task.

Tasks represent our first step toward evolving issues, epics, incidents, requirements, and test cases to work items. If you have feedback or suggestions about tasks, please comment on this issue.

Create tasks in issues

GitOps features are now free

GitOps features are now free

When you use GitOps to update a Kubernetes cluster, also called a pull-based deployment, you get an improved security model, better scalability and stability.

The GitLab agent for Kubernetes has supported GitOps workflows from its initial release, but until now, the functionality was available only if you had a GitLab Premium or Ultimate subscription. Now if you have a Free subscription, you also get pull-based deployment support. The features available in GitLab Free should serve small, high-trust teams or be suitable to test the agent before upgrading to a higher tier.

In the future, we plan to add built-in multi-tenant support for Premium subscriptions. This feature would be similar to the impersonation feature already available for the CI/CD workflow.

Submit merge request review with summary comment

Submit merge request review with summary comment

When you finish reviewing a merge request, there are probably some common things that you do, like summarizing your review for others or approving the changes if they look good to you. Those common tasks are now quicker and easier: when you submit your review, you can add a summary comment along with any quick actions like /approve.

Submit merge request review with summary comment

Add approval rules for all protected branches

Add approval rules for all protected branches

You can now create an MR approval rule and apply it to only protected branches in your project. This is a great improvement that allows you to more selectively apply compliance controls with increased granularity.

Previously, adding an MR approval rule would apply it to all branches. This was a great way to ensure that proper workflows were enforced before code reached production, but it also meant that MRs for feature branches, short-lived branches, or experimental branches all had to use the same workflow. This could slow down developers that did not intend to commit to protected branches and who likely did not need the same level of workflow enforcement.

Creating MR approval rules for protected branches allows you to be confident that the sensitive branches you depend on will have proper workflows applied to them while not slowing down development on other branches that do not need the same level of control.

Add approval rules for all protected branches

UI for custom HTTP headers on streaming audit events

UI for custom HTTP headers on streaming audit events

You can now add and remove custom HTTP headers for streaming audit events directly in the GitLab user interface.

This makes it easy to interface with other systems that expect specific header values to be present and means that you can use a UI-based workflow instead of going through the API.

UI for custom HTTP headers on streaming audit events

Define password complexity requirements

Define password complexity requirements

GitLab administrators can now define password complexity requirements in addition to minimum password length. For new passwords, you can now require:

  • Numbers.
  • Uppercase letters.
  • Lowercase letters.
  • Symbols.

Complex passwords are less likely to be compromised, and the ability to configure password complexity requirements helps administrators enforce their password policies.

Thank you Martin Tan, Kun Qian, and Shuang Zhang for your contribution!

Define password complexity requirements

DORA custom reporting for data-driven software development improvements

DORA custom reporting for data-driven software development improvements

Building on top of our recent added support for DORA metrics, we have added new DORA query parameters to Insights. With this new visualization, software leaders can track metrics improvements, understand patterns in their metrics trends, and compare performance between groups and projects.

Insights reports are configured with a YAML file and can be shared across the organization as a single place for everyone to see the same metrics in the relevant context. In addition to DORA, Insights allows users to create custom reports to explore data such as issues created and closed, bugs created, merge requests, regressions, missed deadlines, track labeled issues, and much more.

DORA custom reporting for data-driven software development improvements

Simulate default branch pipeline in the Pipeline Editor

Simulate default branch pipeline in the Pipeline Editor

The pipeline editor helps prevent syntax errors in your pipeline before you commit. But pipeline logic issues are harder to spot. For example, incorrect rules and needs job dependencies might not be noticed until after you commit and try running a pipeline.

In this release, we’ve brought the ability to simulate a pipeline to the pipeline editor. This was previously available in limited form in the CI Lint tool, but now you can use it directly in the pipeline editor. Use it to simulate a new pipeline creation on the default branch with your changes, and detect logic problems before you actually commit!

15.3 Other improvements in GitLab 15.3

Audit event for changes to audit event custom headers

Audit event for changes to audit event custom headers

GitLab now records an audit event when a custom HTTP header is added or removed for streaming audit events.

This audit event helps you to ensure that your configuration for streaming audit events is correct and that you can:

  • Identify when changes happen for an audit.
  • Identify when you need to take action.

Until now, SAML group links had to be configured in the UI. Now, you can manage SAML group links programmatically using the API so you can automate SAML groups management.

Your GitLab SSH fingerprints are now easier to find, thanks to new links on the SSH configuration page and in the documentation.

Thank you Andreas Deicha for your contribution!

New links to SSH fingerprints

User ID added to profile page

User ID added to profile page

The user ID is now available on the user profile page, including the ability to copy the ID. This will make tasks such as automation easier. Thanks to Andreas Deicha for this community contribution.

Enforce authorization checks for all media files

Enforce authorization checks for all media files

Images attached to issues, merge requests, or comments did not require authentication to be viewed if you knew the direct URL of the attachment. In some cases, this wasn’t enough security for compliance-minded organizations.

Authorization checks are now enabled by default for all projects, and can be configured in the UI or via the projects API to meet your organizational needs. Authentication checks may cause issues for email clients or other external services, which can’t create a valid GitLab session to authenticate.

Visualize table of contents in the WYSIWYG wiki editor

Visualize table of contents in the WYSIWYG wiki editor

When you’re editing a wiki page in the rich text WYSIWYG editor, you expect to see an accurate representation of the content as it will appear after it’s published. Some elements are too complex for plain text formatting, and require short codes or macros that generate content when the page is built. A wiki’s table of contents is one example: it generates a list from your page’s subheadings, simplifying navigation of very long pages. However, WYSIWYG page editing displayed a table of contents as a static placeholder block.

GitLab 15.3 shows a visual representation of the Table of Contents in the WYSIWYG wiki editor. To add a table of contents while editing a page, select the plus (+) icon in the toolbar, then select Table of Contents. The table of contents updates in real time as you create and edit subheadings on the page, helping you monitor the outline of your longer wiki pages.

Improved behavior of CI/CD changes with new branches

Improved behavior of CI/CD changes with new branches

Configuring CI/CD jobs to run on pipelines when certain files are changed by using rules: changes is very useful with merge request pipelines. It compares the source and target branches to see what has changed, and adds jobs as needed. Unfortunately, changes does not work well with branch pipelines. For example, if the pipeline runs for a new branch, changes has nothing to compare to and always returns true, so jobs might run unexpectedly.

In this release we’re adding compare_to to rules:changes for both jobs and workflow:rules, to improve the behavior in branch pipelines. You can now configure your jobs to check for changes between the new branch and the defined comparison branch. Jobs that use rules:changes:compare will work the way you expect, comparing against the branch you define. This is useful for monorepos, where many independent jobs could be configured to run based on which component in the repo is being worked on.

Rebase a merge request from the UI without triggering a pipeline

Rebase a merge request from the UI without triggering a pipeline

In large and busy monorepos with semi-linear branching, you might need to rebase your merge requests frequently. To save resources, you might not want to run a pipeline each time you rebase. You could skip the pipeline while rebasing with the API, or by using Git push options or [ci skip] in a commit message, but not when rebasing from the UI in a merge request.

Now we have an option to skip the pipeline when rebasing from the UI, so you have better control over when a pipeline runs for your merge requests. Thanks to Kev for the contribution!

View your runners’ upgrade status

View your runners’ upgrade status

For GitLab administrators responsible for operating and maintaining a fleet of runners, it can be time-consuming and inefficient to try to determine how many and which runners aren’t using the latest version of GitLab Runner. In 15.1, in the Admin Area on the Runners page, badges were added to individual runners to show when an upgrade was available or recommended. In 15.2, you can filter the list by the upgrade status.

In 15.3, you can view two new summary status badges that indicate how many runners have versions that are out-of-date. The first badge shows how many runners have an upgrade recommended, and the second shows how many have an optional upgrade available. With these new additions, administrators can more easily identify runners that require version updates.

View your runners' upgrade status

Create annotated tags using the Release CLI

Create annotated tags using the Release CLI

Previously, you were only able to create lightweight tags when using the GitLab Release CLI 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 application can have additional context.

Edit all release details by using Edit tag button

Edit all release details by using Edit tag button

We have updated the edit tag workflow so it navigates to edit the release. Previously, it led to a legacy edit tag page. Now you can more easily create or update the related release information, including release notes, and take advantage of other supported functionality such as webhooks for the new release.

DAST API and API Fuzzing speed improvements

DAST API and API Fuzzing speed improvements

As a part of our on-going efforts to improve the speed of testing APIs with DAST API scanning and API Fuzzing, we have added support for multi-CPU runners. API tests, like any tests on running applications, can take a long time to cover all operations with all test cases. The time that it takes to scan an API with a large number of operations can often discourage teams from including these tests in their pipelines, especially pipelines, such as feature branch pipelines, that are sensitive to execution time. The use of multi-CPU runners allows DAST API scans or API Fuzzing tests to be executed in parallel automatically. This significantly reduces the time needed to complete security testing of your APIs.

In our benchmark tests, using a private runner with 3 CPUs increased the test speed by ~78%. Real numbers will vary depending on a number of factors, including the speed of the API being tested and the test modules that have been enabled. In general, when using runners with multiple CPUs, you can expect a significant reduction in test time over using shared runners or runners with a single CPU.

IaC Scanning rules for secret detection now disabled

IaC Scanning rules for secret detection now disabled

We’ve updated GitLab IaC Scanning to disable built-in rules that detected secret tokens and values. These rules were added in the upstream project that powers IaC Scanning (kics).

If you previously had IaC Scanning findings in the “Passwords and Secrets” family, they will show as “No longer detected” after the analyzer updates.

This change prevents duplicate findings when both GitLab Secret Detection and GitLab IaC Scanning are run in the same project. We expect this change to improve scanning performance by removing expensive pattern matching.

We are tracking work to ensure that the removed rules are all covered by built-in rules in GitLab Secret Detection.

License compliance analyzer updates

License compliance analyzer updates

GitLab License Compliance supports gathering license data by running the license-finder analyzer. This analyzer has been updated to use a Debian Bullseye base image instead of the previous Debian Buster base image.

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

  • Kics analyzer updated to add additional rules, fix bugs, and update to kics version 1.5.12. See CHANGELOG for details.
  • NodeJSScan analyzer updated to fix an issue scanning repositories that contain symlinks. See CHANGELOG for details.
  • PMD-Apex analyzer updated to version 6.47.0. This update resolves a security vulnerability in a PMD dependency. See CHANGELOG for details.
  • Semgrep analyzer updated. See CHANGELOG for details.
  • Secrets analyzer updated to fix handling of custom certificate authorities (CAs) in OpenShift. See CHANGELOG for details.
  • SpotBugs analyzer updated to include new versions of SpotBugs, Gradle, Grails, Maven, sbt, Java, and other dependencies, and to fix handling of custom certificate authorities (CAs) in OpenShift. 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.

For previous changes, see last month’s updates.

Geo supports project-level secure files

Geo supports project-level secure files

Geo now supports replication and verification of project-level secure files across Geo sites. With project-level secure files you can upload binary files, such as profiles, certificates, and keystores, to projects in GitLab and use them in CI/CD jobs.

Omnibus improvements

Omnibus improvements

  • GitLab 15.3 includes Mattermost 7.1 with a new Insights dashboard and more. This version also includes security updates and upgrade from earlier versions is recommended.
  • Gitaly is now using new cgroup configurations. The following configs are to be deprecated: gitaly['cgroups_count'], gitaly['cgroups_memory_limit'], gitaly['cgroups_memory_enabled], and gitaly['cgroups_cpu_enabled']. If you use any of the previous settings, ensure you remove them or switch to the new ones, before the 16.0 major release.
  • Starting in 15.3, the bundled Grafana will be disabled by default for new installations. The version of Grafana we bundle with Omnibus has a security vulnerability and is now deprecated.

Fortinet push notification support for Git over SSH

Fortinet push notification support for Git over SSH

In previous version of GitLab, one-time passwords (OTP) were the only option when using FortiAuthenticator for two factor authentication. This option requires the user to type in this OTP each time it is presented.

Now, users can choose to receive a push notification instead of an OTP, allowing users to verify themselves more quickly.

Migrate multiple MR assignees when migrating groups

Migrate multiple MR assignees when migrating groups

As part of our effort to improve and iterate on group migration by adding more metadata to the migrated groups and projects and creating a great migration experience. We are adding support for migrating multiple assignees to a merge request.

Prior to this milestone, only a single merge request assignee could be migrated. This will help automate migrations and save time from eliminating the manual work of assigning all the assignees that were assigned prior to the migration.

Secure defaults for new access tokens

Secure defaults for new access tokens

When you create access tokens, the following defaults are displayed:

  • Expiration date is 30 days from the current date.
  • For project and group access tokens, the role is Guest.

Previously, there were no defaults in place. By setting a default expiration date and pre-selecting the least privileged role, GitLab provides a more secure baseline from which to create a token.

User SCIM identity visible in UI

User SCIM identity visible in UI

Previously, the SCIM identity for a user could only be accessed using the SCIM API.

Now, a user’s SCIM identity is visible to GitLab administrators in the Identities tab of the User list. With this, troubleshooting of SCIM-related issues is simplified. Administrators can validate what identity, if any, is being used for a specific account without requiring GitLab Support or an API query.

Remove approvals by Code Owners if their files changed

Remove approvals by Code Owners if their files changed

To ensure that merge request approvals are about the latest proposed changes, you may remove approvals when more changes are added. However, this kind of removal can be impractical if you also require Code Owners to approve changes for specific files or paths. Even if the new changes don’t affect the files that a Code Owner is responsible for, their approval is removed.

Now you can be more selective and only remove Code Owner approvals if their files changed, increasing the speed of code review by avoiding unnecessary re-approvals.

Thank you Lee Tickett for your contribution!

GitLab Runner 15.3

GitLab Runner 15.3

We’re also releasing GitLab Runner 15.3 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:

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

Improved details and editing for group runners

Improved details and editing for group runners

If you’re a group owner, when you’re viewing a runner’s details, the redesigned details page has an improved layout. The runner’s metadata is displayed more compactly and you can edit the runner from the new view. These changes help make the experience of managing runners easier and more efficient.

Improved details and editing for group runners

View your group runners’ upgrade status

View your group runners’ upgrade status

If you have to manage a fleet runners for your group, it can be time-consuming and inefficient to try to determine how many and which runners aren’t using the latest version of GitLab Runner. Failing to update the version 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 15.3, the list view shows two new summary status badges that indicate how many runners have versions that are out-of-date. The first badge shows how many runners have an upgrade recommended, and the second shows how many have an optional upgrade available. You can also view the status for individual runners, as well as filter the list by status. With these new additions, you can more easily identify runners that require version updates.

View your group runners' upgrade status

Create annotated tags by using release:tag_message keyword

Create annotated tags by using release:tag_message keyword

You can now create an annotated tag when you create a release. In the .gitlab-ci.yaml file, use the release keyword to include an optional tag_message subkey and specify a message. This enables you to include relevant information along with the new tag, so downstream users and applications can have additional context.

Delete deployments by using the API

Delete deployments by using the API

You can now delete deployments by using the API. This change allows you to manage and clean up old deployments refs.

Group-level protected environment configuration in project settings page

Group-level protected environment configuration in project settings page

Previously, there was no way to see if there are related group-level protected environment settings when viewing a project’s configuration settings. In 15.3, you can now see these settings in the project’s protected environment configuration settings page.

Browser-based DAST passive check milestone

Browser-based DAST passive check milestone

Browser-based DAST scans now run all passive vulnerability checks from the browser-based analyzer! While browser-based DAST is still in an opt-in beta state, we have been releasing new vulnerability checks on a regular basis. Once each of these are finished and enabled in the browser-based analyzer, they are simultaneously disabled in the legacy proxy-based analyzer. Any checks that have not been ported over to the new analyzer are still run in the legacy analyzer, to ensure full vulnerability coverage for all tests. As of 15.3, we have completely switched all passive checks over to the new analyzer. This marks a major milestone in the development of our new analyzer.

Going forward, we will be working on active vulnerability check development. As with the passive checks, the individual active checks will be enabled as they are released, for any scan where the DAST environment variable DAST_BROWSER_SCAN is set to true.

Exclude paths from Secure scanning with double-star globs

Exclude paths from Secure scanning with double-star globs

We’ve improved the way you can ignore paths in GitLab Secure scanners. Ignoring paths can help you focus on the right findings by ignoring test files, example code, or other code you don’t want to scan.

You can now use double-star glob patterns like **/*_test.go or test/**/fixture* to exclude paths in:

Improved design for license compliance MR widget

Improved design for license compliance MR widget

The license compliance merge request widget has a redesigned user experience that brings the following improvements:

  • Better consistency with the other widgets.
  • Improved readability through indentation.
  • A more clean overall stylistic look and feel.
Improved design for license compliance MR widget

Preview upcoming SAST analyzer consolidations

Preview upcoming SAST analyzer consolidations

You can now test upcoming changes by using the Latest variant of the GitLab-managed SAST CI/CD template in your pipeline. This is part of our iterative plan to replace language-specific GitLab SAST analyzers with Semgrep-based scanning, as announced in 15.0.

In GitLab 15.3, we’ve amended the latest template so that the Semgrep analyzer replaces the deprecated analyzers bandit, gosec, and eslint. We recommend that you test this change in a merge request but stay on the Stable template in your default branch pipeline configuration. To learn more about the change, see documentation on the transition to Semgrep-based scanning.

The latest template contains all changes that we plan to release in the Stable template in GitLab 15.4. To learn more about Stable and Latest templates, see documentation on CI/CD template versioning.

Interactive security policy editor validation

Interactive security policy editor validation

GitLab’s security policy YAML editor now includes automatic inline validation. This validation helps prevent common YAML formatting errors and gives you live feedback on your policy as you type.

Improve the accuracy of repository size calculation

Improve the accuracy of repository size calculation

We are working hard to make the repository size displayed in GitLab more accurate by improving how we calculate the size of a repository. We are doing this to give a more accurate picture of how much disk space your repositories use.

In the past, we included shared objects that were a part of the pool repository in our calculation. We have revised our calculation methods to no longer include these shared objects, and provide a more accurate representation of your repositories’ actual storage space. As a result, calculated storage for forked projects now only includes the git changes as opposed to the entire git repository.

While this is an improvement to repository size calculation, it is not perfect. There are still situations where the calculated repository size can differ from what is expected, and we are investigating ways to fix this situation.

Safe method to remove Praefect database records

Safe method to remove Praefect database records

In some cases Gitaly Cluster may create a database entry for a repository but fail to replicate the on-disk data. You can now manually remove the Gitaly Cluster database entries while leaving the on-disk repository intact by using the -db-only option. This allows administrators to remove orphaned database entries while protecting on-disk repositories.

To re-track a repository, use the track-repository command.

Bug fixes, performance improvements, and usability improvements

Bug fixes, performance improvements, and usability 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 usability. 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 usability improvements we’ve delivered in 15.3.

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.

  • Security report schemas version 14.x.x
  • Use of `id` field in vulnerabilityFindingDismiss mutation
  • Atlassian Crowd OmniAuth provider
  • Redis 5 deprecated
  • CAS OmniAuth provider
  • 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 15.3

    GitLab versions 15.3.0 - 15.3.4 were affected by a licensing cache issue which meant some premium features of GitLab will stop working if you add a new license. Workarounds for this issue include: - Restarting all Rails, Sidekiq, and Gitaly nodes after applying a new license. This clears the relevant license caches and allows all premium features to operate correctly. - Upgrading to a version that is not impacted by this issue, for example 15.3.5.


    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