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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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.
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.
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.
We’ve updated to Semgrep version 0.104.0 to improve performance, fix bugs, and otherwise improve the scanning engine.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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:
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.
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.
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.
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.
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.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.
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