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.
Include or exclude archived projects from project search results:
Global Search
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.
Kubernetes 1.27 support:
Deployment Management
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.
Wrap feature flag names instead of truncating:
Feature Flags
Omnibus improvements (self-managed only):
Omnibus Package
security updates and upgrading from earlier versions is recommended.
generally available and was replaced with Amazon Linux 2023, so we have adjusted our offering to the updated release.
Until now, the BitBucket Server importer did not import pull request (PR) reviewers and instead categorized them as participants. Information on PR reviewers is In GitLab 16.3, we added support for correctly importing PR reviewers from BitBucket. In GitLab, they become merge request reviewers.
Preserve pull request reviewers when importing from BitBucket Server:
Importers
important from an audit and compliance perspective.
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 With these new application settings, both self-managed GitLab and GitLab.com administrators can adjust these limits as needed.
Configurable import limits available in application settings (self-managed only):
Importers
Previously hardcoded at 5 GB. On GitLab.com, we've set this limit to 5 GB.
Previously hardcoded at 10 GB. On GitLab.com, we've set this limit to 10 GB.
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 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.
New navigation has color themes available:
Navigation & Settings
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.
No entity export timeout for migrations by direct transfer:
Importers
In previous releases, you probably used Deployments rely on Flux Flux sync status visualization:
Environment Management
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.
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.
Verify
Pipeline names defined with the Expose pipeline name as a predefined CI/CD variable:
Continuous Integration (CI)
workflow:name
keyword are now accessible via the predefined variable $CI_PIPELINE_NAME
.
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.
GitLab Runner 16.3:
GitLab Runner Core
What's new:
Bug Fixes:
The Previously, it was impossible to use the Use the
needs
keyword with parallel jobs: Pipeline Composition
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.
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!
Secure
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:
If you include the GitLab-managed SAST template ( For previous changes, see last month's updates.
SAST analyzer updates:
SAST
toolExecutionNotifications
of level error. See the CHANGELOG for further details.
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.