doc/releases/16/gitlab-16-3-released.md
On August 22, 2023, GitLab 16.3 was released with the following features.
In addition, we want to thank all of our contributors, including this month's notable contributor.
Thomas has contributed 15 merge requests to the GitLab agent for Kubernetes Helm chart in the last month!
Thomas made the chart more mature in terms of security and observability, made it simpler to troubleshoot issues with agentk, and improved the CI/CD pipeline to check for breaking changes.
As a security engineer, Thomas enjoys collaborating with the team to provide a more secure default deployment of the GitLab agent. Thomas expressed thanks for all the timely reviews and feedback, which team members were more than happy to provide.
Thank you Thomas, your contributions are hugely appreciated! 🙌
We would also like to take the opportunity to thank Shane Maglangit and Batuhan Apaydın for their great contributions.
{{< details >}}
{{< /details >}}
The Value Streams Dashboard has been enhanced with new metrics: Merge request (MR) throughput and Total closed issues (Velocity). In GitLab, MR throughput is a count of the number of merge requests merged per month, and Total closed issues is the number of flow items closed at a point in time.
With these metrics, you can identify low or high productivity months and the efficiency of merge request and code review processes. You can then gauge whether the Value Stream delivery is accelerating or not.
Over time, the metrics accumulate historical data from MRs and issues. Teams can use the data to determine if delivery rates are accelerating or need improvement, and provide more accurate estimates or forecasts for how much work they can deliver.
To help us improve the Value Streams Dashboard, please share feedback about your experience in this survey.
{{< details >}}
{{< /details >}}
With Workspaces, you can create reproducible, ephemeral, cloud-based runtime environments. Since the feature was introduced in GitLab 16.0, the only way to use a workspace was through the browser-based Web IDE running directly in the environment. The Web IDE, however, might not always be the right tool for you.
With GitLab 16.3, you can now securely connect to a workspace from your desktop with SSH and use your local tools and extensions. The first iteration supports SSH connections directly in VS Code or from the command line with editors like Vim or Emacs. Support for other editors such as JetBrains IDEs and JupyterLab is proposed in future iterations.
{{< details >}}
{{< /details >}}
In previous releases, you probably used kubectl or another third-party tool to check the status of your Flux deployments. From GitLab 16.3, you can check your deployments with the environments UI.
Deployments rely on Flux Kustomization and HelmRelease resources to gather the status of a given environment, which requires a namespace to be configured for the environment. By default, GitLab searches the Kustomization and HelmRelease resources for the name of the project slug. You can customize the name GitLab looks for in the environment settings.
{{< details >}}
{{< /details >}}
Determining which results from a security or compliance scan are actionable is a significant challenge for security and compliance teams. Granular filters for scan result policies will help you cut through the noise to identify which vulnerabilities or violations require your attention the most. These new filters and filter updates will streamline your workflows:
new_needs_triage allows you to filter only new vulnerabilities that need to be triaged.{{< details >}}
{{< /details >}}
You can now see security findings directly in Visual Studio Code (VS Code), just as you would in a merge request.
You could already monitor the status of your CI/CD pipeline, watch CI/CD job logs, and move through your development workflow in the GitLab Workflow panel. Now, after you create a merge request for your branch, you can also see a list of new security findings that weren’t previously found on the default branch.
This new feature is part of GitLab Workflow for VS Code. Security scan results are pulled from an API, so this feature is available to developers using GitLab.com or self-managed instances running GitLab 16.1 or higher.
needs keyword with parallel jobs{{< details >}}
{{< /details >}}
The needs keyword is used to define dependency relationships between jobs. You can use the keyword to configure jobs to be dependent on specific earlier jobs instead of following stage ordering. When the dependent jobs complete, the job can start immediately, speeding up your pipeline.
Previously, it was impossible to use the needs keyword to set parallel matrix jobs as dependent, but in this release, we have enabled the ability to use needs with parallel matrix jobs too. You can now define a flexible dependency relationship to parallel matrix jobs, which can help speed up your pipeline even more! The earlier your jobs can start, the earlier your pipeline can finish!
{{< details >}}
{{< /details >}}
Having recently upgraded all of our Linux SaaS runners, we are now introducing xlarge and 2xlargeSaaS runners on Linux. Equipped with 16 and 32 vCPUs respectively and fully integrated with GitLab CI/CD, these runners will allow you to build and test your application faster than ever before.
We are determined to provide the industry’s fastest CI/CD build speed and look forward to seeing teams achieve even shorter feedback cycles and ultimately deliver software faster.
{{< details >}}
{{< /details >}}
Secrets stored in Azure Key Vault can now easily be retrieved and used in CI/CD jobs. Our new integration simplifies the process of interacting with Azure Key Vault through GitLab CI/CD, helping you streamline your build and deploy processes!
{{< details >}}
{{< /details >}}
You can now opt to include or exclude archived projects from search results. By default, archived projects are excluded. This feature is available for project search in GitLab. Support for other global search scopes is proposed in future releases.
{{< details >}}
{{< /details >}}
{{< details >}}
{{< /details >}}
Application setting changes at an instance, project, and group level are now recorded in the audit log, along with which user made the change. This improves auditing of application settings for both self-managed and SaaS.
{{< details >}}
{{< /details >}}
Until now, the BitBucket Server importer did not import pull request (PR) reviewers and instead categorized them as participants. Information on PR reviewers is important from an audit and compliance perspective.
In GitLab 16.3, we added support for correctly importing PR reviewers from BitBucket. In GitLab, they become merge request reviewers.
{{< details >}}
{{< /details >}}
Hardcoded limits exist for both migration by direct transfer and by importing export files.
In this release, we’ve made some of these limits configurable in application settings to allow self-managed GitLab administrators to adjust them according to their needs:
We’ve also added a new
maximum decompressed file size for imported archives
application setting, which replaces the validate_import_decompressed_archive_size feature flag. This limit was hardcoded to 10 GB. On GitLab.com, we’ve set this limit to 25
GB.
With these new application settings, both self-managed GitLab and GitLab.com administrators can adjust these limits as needed.
{{< details >}}
{{< /details >}}
With the new navigation enabled, you can now select one of five different color themes, and choose the light or dark variety for each. Use themes to identify different environments or choose your favorite color.
{{< details >}}
{{< /details >}}
Until now, migrating groups and projects by direct transfer had a 90 minute export timeout. This limit effectively excluded large projects from being migrated, because only projects that could be migrated in under 90 minutes were allowed.
The upper limit for the overall migration timeout is 4 hours, and so the 90 minutes export timeout was not necessary. In this milestone, the limit was removed, allowing larger projects to be migrated.
{{< details >}}
{{< /details >}}
GitLab SAML Group Sync now supports the Azure AD (now known as Entra ID) overage claim, which allows a user to have over 150 groups associated with them. The previous maximum was 150 groups. For more information, see Microsoft group overages.
{{< details >}}
{{< /details >}}
Geo is now able to detect and correct data corruption of group wikis at rest and in transit. If you use Geo as part of your disaster recovery strategy, this helps to protect you against data loss in the event of a failover.
{{< details >}}
{{< /details >}}
You can now see in the UI if your CODEOWNERS file has syntax or formatting errors. Being able to specify code owners offers great flexibility, allowing multiple file locations, sections, and rules to be configured by users. With this new syntax validation, errors in your CODEOWNERS file will be surfaced in the GitLab UI, making it easy to spot and fix issues. The following errors will be surfaced:
Previously, the CODEOWNERS file didn’t validate the information being entered into the file. This could lead to creating:
{{< details >}}
{{< /details >}}
This release adds full support for Kubernetes version 1.27, released in April 2023. If you use Kubernetes, you can now upgrade your clusters to the most recent version and take advantage of all its features.
You can read more about our Kubernetes support policy and other supported Kubernetes versions.
{{< details >}}
{{< /details >}}
If you used feature flags in previous versions of GitLab, you might have noticed that long feature flag names were truncated. This made it difficult to quickly differentiate similar feature flag names.
In GitLab 16.3, the entire feature flag name is shown. Long names wrap across multiple lines, if needed.
{{< details >}}
{{< /details >}}
Previously, audit event streaming destinations were assigned by the destination URL. This could lead to confusion when you set up multiple streams for one group or instance, because you had to expand the destination in the UI to see what filters and custom headers had been applied.
With GitLab 16.3, you can now name audit event streaming destinations to help identify and differentiate them when you have multiple streaming destinations defined.
{{< details >}}
{{< /details >}}
GitLab surfaces vulnerabilities that contain relevant information, however, sometimes it is unclear where to start. It takes time to research and synthesize information that is surfaced within the vulnerability record. Moreover it can be difficult to figure out how to fix a given vulnerability. With this Beta release, you can click a button to get an explanation and recommendation on how to mitigate the vulnerability, generated by AI.
{{< details >}}
{{< /details >}}
To facilitate the growth of compliance-related features beyond reporting and into management, the Compliance reports section of GitLab was renamed to reflect the expanding scope of the area.
From GitLab 16.3, Compliance reports are known as Compliance center.
{{< details >}}
{{< /details >}}
A scan result policy is a type of security policy you use to evaluate and block merge requests if particular rules are violated. Approvers may review and approve the change, or work with their development teams to address any issues (such as addressing critical security vulnerabilities).
Previously, we compared vulnerabilities in the latest source and target branches to detect any new violations of policy rules. But, this might not capture vulnerabilities detected from scans running as a result of various pipeline sources. To increase accuracy, we are now comparing the latest completed pipelines for each pipeline source (with the exception of parent/child pipelines). This will ensure a more comprehensive evaluation and reduce the cases where approvals are required when it may be unexpected.
{{< details >}}
{{< /details >}}
In GitLab 16.2, we introduced instance-level audit event streaming. However, no filters were available to apply to these streams.
In GitLab 16.3, you can now apply filters by audit event type to instance-level audit event streams. With the addition of these filters in the UI, you can capture a subset of audit events to send to each streaming location, focusing only on the events that are relevant for you.
{{< details >}}
{{< /details >}}
Security bot users will be created to support managing background tasks, and to enforce security policies for all newly created or updated security policy project links. This will ease the process for security and compliance team members to configure and enforce policies, specifically removing the need for security policy project maintainers to also maintain Developer access in development projects. Security policy bot users will also make it much clearer for users within an enforced project when pipelines are executed on behalf of a security policy, as this bot user will be the pipeline author.
When a security policy project is linked to a group or subgroup, a security policy bot will be created in each project in the group or subgroup. When a link is made to a group, subgroup, or an individual project, a security bot user will be created for the given project or for any projects in the group or subgroup. Any groups, subgroups, or projects that already have a link to a security policy project will be unaffected at this time, but users may re-establish any existing links to take advantage of this feature. In GitLab 16.4, we plan to enable security bots on all projects hosted on GitLab.com that have existing security policy project links.
{{< details >}}
{{< /details >}}
GitLab SAST includes many security analyzers that the GitLab Static Analysis team actively maintains, updates, and supports. We published the following updates during the 16.3 release milestone:
toolExecutionNotifications of level error. See the CHANGELOG for further details.If you include the GitLab-managed SAST template (SAST.gitlab-ci.yml) and run GitLab 16.0 or higher, you automatically receive these updates.
To remain on a specific version of any analyzer and prevent automatic updates, you can pin its version.
For previous changes, see last month’s updates.
{{< details >}}
{{< /details >}}
GitLab Dependency and License Scanning now support analyzing Java v21 Maven lock files.
{{< details >}}
{{< /details >}}
You can now use tags to specify which runners you wish to use for on-demand DAST scans. Prior to 16.3, you could configure DAST scans using private runners via CI configuration files. This UI-based configuration enables efficient UI-configuration for managing DAST scans.
{{< details >}}
{{< /details >}}
GitLab SAST Advanced Vulnerability Tracking makes triage more efficient by keeping track of findings as code moves. We’ve released two improvements in GitLab 16.3:
This builds on previous expansions and improvements released in GitLab 16.2. We’re tracking further improvements, including expansion to more languages, better handling of more language constructs, and improved tracking for Python and Ruby, in epic 5144.
These changes are included in updated versions of GitLab SAST analyzers. Your project’s vulnerability findings are updated with new tracking signatures after the project is scanned with the updated analyzers. You don’t have to take action to receive this update unless you’ve pinned SAST analyzers to a specific version.
{{< details >}}
{{< /details >}}
We’ve integrated Secret Detection with Postman to better protect customers who use Postman in their GitLab projects.
Secret Detection searches for Postman API keys. If a key is exposed in a public project on GitLab.com, GitLab sends the leaked key to Postman. Postman verifies the key, then notifies the owner of the Postman API key.
This integration is on by default for projects that have enabled Secret Detection on GitLab.com. Secret Detection scanning is available in all GitLab tiers, but an automatic response to leaked secrets is currently only available in Ultimate projects.
See the Postman blog post about this integration for further details.
{{< details >}}
{{< /details >}}
Pipeline names defined with the workflow:name keyword are now accessible via the predefined variable $CI_PIPELINE_NAME.
{{< details >}}
{{< /details >}}
We’re also releasing GitLab Runner 16.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.
The list of all changes is in the GitLab Runner CHANGELOG.