GitLab 16.1 released with all new navigation, GitLab Dedicated General Availability, Kubernetes resource visualization, authentication with Service Accounts and much more!
These are just a few highlights from the 100+ improvements in this release. Read on to check out all of the great updates below.
We thank the wider GitLab community for the 189 contributions they provided to GitLab 16.1! 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 16.2 release kickoff video.
Gerardo has been consistently iterating over multiple releases to deliver
the REST API endpoints for job token scope.
Iteration is one of our core values
at GitLab, and Gerardo has exemplified that with his multiple contributions to deliver the feature.
Due to the change in default CI_JOB_TOKEN behavior,
users who automate creation of projects cannot also automate adding the projects allowed to use
a CI_JOB_TOKEN with the project. This REST API endpoint enables our customers to automate this
process again and drive increased adoption of a more secure CI_JOB_TOKEN workflow.
Thanks to Gerardo and the rest of the crew from Siemens!
Yuri picked up an issue that
was logged 6 years ago, took a bias for action
(one of our GitLab values) and contributed a fix.
This was a popular feature that a number of customers were interested in. This enhancement
allows the system admin to skip specific projects during backup and restore, based on a comma-separated list of group
or project paths. With this feature, system admins can skip over stale
or archived projects during their backup run, save storage space and speed up the backup.
They can also exclude specific projects when restoring from backup using the same option.
GitLab 16.1 features an all-new navigation experience! We’ve defaulted this experience to on for all users. To get started, go to your avatar in the top right of the UI and turn on the New navigation toggle.
The new navigation was designed to solve three key areas of feedback: navigating GitLab can be overwhelming, it can be hard to pick up where you left off, and you can’t customize the navigation.
The new navigation includes a streamlined and improved left sidebar, where you can:
Pin 📌 frequently accessed items.
Completely hide the sidebar and “peek” it back into view.
Easily switch contexts, search, and view subsets of data with the new Your Work and Explore options.
Scan more quickly because of fewer top-level menu items.
We are proud of the new navigation and can’t wait to see what you think. Review a list of what’s changed and read our blog posts about the navigation vision and design.
Please try the new navigation and let us know about your experience in this issue. We are already addressing the feedback and will eventually remove the toggle.
How do you check the status of the applications running in your clusters? The pipeline status and environment pages provide insights about the latest deployment runs. However, previous versions of GitLab lacked insights about the state of your deployments. In GitLab 16.1, you can see an overview of the primary resources in your Kubernetes deployments.
This feature works with every connected Kubernetes cluster. It doesn’t matter if you deploy your workloads with the CI/CD integration or GitOps. To further improve the feature for Flux users, support for showing the synchronization status of an environment is proposed in issue 391581.
There are many use cases for which a non-human user might need to authenticate. Previously, depending on the desired scope, users could use personal, project, or group access tokens to meet this need. These tokens were not ideal, due to still being either tied to a human (for personal access tokens), or an unnecessarily privileged role (for group and project access tokens).
Service accounts are not tied to a human user, and are more granular in scope. Service account creation and management is API-only. Support for a UI option is proposed in issue 9965.
GitLab Dedicated is a fully managed, single-tenant SaaS deployment of our comprehensive DevSecOps platform designed to address the needs of customers with stringent compliance requirements.
Customers in highly-regulated industries are unable to adopt multi-tenant SaaS offerings due to strict compliance requirements like data isolation. With GitLab Dedicated, organizations can access all of the benefits of the DevSecOps platform – including faster releases, better security, and more productive developers – while satisfying compliance requirements such as data residency, isolation, and private networking.
Previously, if you wanted to view or manage job artifacts, you had to go to each job’s detail page, or use the API. Now, you can view and manage job artifacts through the Artifacts page accessed at Build > Artifacts.
Users with at least the Maintainer role can use this new interface to delete artifacts too. You can delete individual artifacts, or bulk delete up to 100 artifacts at a time through either manual selection or checking the Select all option at the top of the page.
Please use the survey at the top of the Artifacts page to share any feedback you have about this new functionality. To view additional UI features under consideration, you can check out the Build Artifacts page enhancements epic.
CI/CD variables are a key part of all pipelines and can be defined in multiple places, including in the project and group settings. To prepare for making bigger improvements that will help users intuitively navigate between variables at different hierarchy, we are starting out with improving the usability and layout of the variable list.
In GitLab 16.1, you will see the first iteration of these improvements. We have merged the “Type” and “Options” columns into a new Attributes column, which better represents these related attributes. We appreciate your feedback on how we can continue to improve the CI/CD variable experience, you are welcome to comment in our variables improvement epic.
Domain verification serves multiple purposes across GitLab. Previously, in order to verify a domain, you had to complete the GitLab Pages wizard, even if you were verifying a domain for a purpose outside of GitLab Pages.
Now, domain verification lives at the group level, and has been streamlined. This makes it easier to verify your domains.
If you forget your GitLab password, you can now reset it by email with any verified email address. Previously, only the primary email address was used for reset requests. This made it difficult to complete the password reset process if the primary email inbox was inaccessible.
Administrators can prevent users from deleting their account with a new user restrictions configuration setting. If this setting is enabled, users will no longer be able to delete their accounts, preserving auditable account information.
The ability to view the vulnerability report is now split into a separate permission, enabling GitLab administrators and group owners to create a custom role with this permission. Previously, viewing the vulnerability report was limited to the Developer role and above. Now, any user can view the vulnerability report, as long as they are assigned a custom role that has the permission.
You can now configure the static file directory for GitLab Pages to any name (by default public).
This makes it easier to use Pages with popular static site frameworks such as Next.js, Astro, or Eleventy,
without needing to change the output folder in their configuration.
Changelogs generate comprehensive lists of changes based on commits to a project. They can be challenging to automate or view, and require interacting with the GitLab API.
With the release of GitLab CLI v1.30.0 you can now generate changelogs for projects directly from your shell. The glab changelog generate command makes it easier to review, automate, and publish changelogs.
Starting in GitLab 16.0, the default CI/CD job token (CI_JOB_TOKEN) scope changed for all new projects. This increased the security of new projects, but added an extra step for users who used automation to create projects. The automation sometimes has to configure the job token scope as well, which could only be done with GraphQL (or manually in the UI), not the REST API.
To make this setting configurable through the REST API as well, Gerardo Navarro added a new endpoint to control the job token scope in 16.1. It is available to users with a Maintainer or higher role in the project. Thank you for this great contribution Gerardo!
We’re also releasing GitLab Runner 16.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.
The new runner creation method enables you to re-use a runner configuration for scenarios where you may need to register multiple runners with the same capabilities. Runners registered with the same authentication token share a configuration and are grouped in the new detailed view.
For Service Desk requesters, it can be helpful to access the Service Desk issue directly rather than interact with the Service Desk request only via email. We are introducing a new placeholder %{ISSUE_URL}, that you can use in your email templates (for example, the “thank you” email) to link requesters directly to the Service Desk issue.
The built-in backup and restore tool adds the ability to skip specific repositories. The Rake task now accepts a list of comma-separated group or project paths to be skipped during the backup or restore by using the new SKIP_REPOSITORIES_PATHS environment variable. This will allow you to skip, for example, stale or archived projects which do not change over time, saving you a) time by speeding up the backup run, and b) space by not including this data in the backup file.
Thanks to Yuri Konotopov for this community contribution!
When you add a design to an issue, a design Git repository is created or updated, and an LFS object and an upload (for the thumbnails) are created. Geo already verifies LFS objects and uploads, and now it also verifies the design repositories as well. Now that all underlying data of Design Management is verified, your design data is ensured to not be corrupted in transfer or at rest. If Geo is used as part of a disaster recovery strategy, this protects you against data loss.
More clearly explain the type of weakness each rule targets and how to fix it. We’ve updated the description and guidance text for C, C#, Go, and Java rules so far. The remaining languages are tracked in issue 382119.
Catch additional vulnerabilities in existing Java rules.
These improvements are part of a collaboration between the GitLab Static Analysis and Vulnerability Research teams to improve the default Static Analysis rulesets.
We would welcome any feedback on the default rules for SAST, Secret Detection, and IaC Scanning in epic 8170.
For more details on the changes to GitLab SAST rules, see the CHANGELOG.
As of GitLab 16.1, the sast-rules project is the single source of all GitLab-managed default rules used in the Semgrep-based SAST analyzer.
Security and compliance policies allow organizations to enforce checks and balances across multiple projects to align with their security and governance programs. It’s critical for our customers to ensure changes that impact policies do not result in the guardrails coming down. With this update, invalid rules will “fail closed”, blocking MRs until invalid rules in any scan result policies are addressed.
Change fields in predefined rules, including the description, message, name, or severity, to reflect organizational preferences. For example, you could adjust the default severity of a rule or add information about how to remediate a finding.
Build a custom ruleset by adding or replacing rules. This option is available only for some analyzers.
Further improvements in this area are discussed in an issue.
When a GitHub project finished importing, GitLab showed a simple summary of imported entities. However, GitLab didn’t show exactly which GitHub
entities failed to import nor the errors that caused the import failures. This made it difficult to decide if import results were satisfactory or not.
In this release, we have extended the import summary to include a list of GitHub entities that weren’t imported and, if possible, provide
a direct link to these entities on GitHub. GitLab now also shows an error for each failure. This helps you understand how well the import worked
and helps you troubleshoot problems.
The last_used value for personal access tokens (PAT) was previously updated every 24 hours. It is now updated every 10 minutes. This increases visibility of PAT usage and, in the case of PAT compromise, reduces risk because it takes less time before malicious activity is noticed.
Shibboleth OmniAuth support has been re-introduced to GitLab. It was previously removed in GitLab 15.9 due to lack of upstream support. Thanks to a generous community contribution by lukaskoenen, who took on upstream support, omniauth-shibboleth-redux is now supported in self-managed GitLab.
GitLab administrators can use Admin Mode to work as a non-administrator user, and turn on administrator access when needed. Previously, an administrator’s personal access token (PAT) always had permissions to perform API actions as an administrator. Now, when adding a PAT, an administrator can decide if that PAT has administrator access to perform API actions or not, by selecting the Admin Mode scope. An administrator must enable Admin Mode for the instance to use this feature.
Currently the Design uploads have no metadata to explain their purpose, or why they are being uploaded. We’ve added a text box as a description so you can help users understand the image better.
Merge requests now support commenting on an entire file, because not all merge request feedback is line-specific. If a file is deleted, you might want more information about why. You might also want to provide feedback about a filename, or general comments about structure.
One of GitLab’s most used features is CI/CD. In 16.1, we focused on improving the usability and experience of CI/CD pipeline and job list views, as well as the pipeline details page. It’s now easier to find the information you are looking for! If you have any comments about the changes, we’d love to hear from you in our feedback issue.
The needs: keyword defines a dependency relationship between jobs, which you can use to set jobs to run out of stage order. In this release we’ve added the ability to define this relationship for specific rules conditions. When a condition matches a rule, the job’s needs configuration is completely replaced with the needs in the rule. This can help speed up a pipeline based on your defined conditions, when a job can start earlier than normal. You can also use this to force a job to wait for an earlier one to complete before starting, you now have more flexible needs options!
After recently upsizing our GitLab.com SaaS runners on Linux in vCPU and RAM, we have now also increased the storage for medium and large machine types.
You can now seamlessly build, test, and deploy larger applications that require a secure, on-demand GitLab Runner Linux environment fully integrated with GitLab CI/CD.
You can use your project’s Package Registry to publish and install npm packages. You simply authenticate using an access token (personal, job, deploy, or project) and start publishing packages to your GitLab project.
This works great if you have a small number of projects. Unfortunately, if you have multiple projects, you might quickly find yourself adding dozens or even hundreds of different sources. It is common for teams in large organizations to publish packages to their project’s Package Registry alongside the source code and pipelines. Simultaneously, they need to be able to easily install dependencies from other projects within the groups and subgroups in their organization.
To make sharing packages easier between projects, you can now install packages from your group so you don’t have to remember which package lives in which project. Using an authentication token of your choice, you can install any of the group npm packages after you add your group as a source for npm packages.
When a requester replies to a Service Desk email, it is useful to the Service Desk agent to know who made the comment. But because the requester can be an external user with no GitLab account or access to the GitLab project, these comments were previously attributed to the GitLab Support Bot. From now on, email replies from requesters will be attributed to the external users, making it more clear who made the comments in the GitLab issue.
Geo adds filtering by replication status to all components managed by the self-service framework. Now you can filter items in the replication details views by “In progress”, “Failed”, and “Synced” status making it easier and faster to locate data that is failing to synchronize.
GitLab 16.1 replaces busybox Docker image with gitlab-base Docker image to share layers with other GitLab
Docker images. This implementation treats gitlab-base as a helper image (like kubectl and certificates),
with optional local overrides.
We’ve integrated Secret Detection with Google Cloud to better protect customers who use GitLab to develop applications on Google Cloud. Now, if an organization leaks a Google Cloud credential to a public project on GitLab.com, GitLab can automatically protect the organization by working with Google Cloud to protect the account.
Secret Detection searches for three types of secrets issued by Google Cloud:
Publicly leaked secrets are sent to Google Cloud after they’re discovered. Google Cloud verifies the leaks, then works to protect customer accounts against abuse.
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.
GitLab Code Quality supports integrating tools you already run and also offers a CI/CD template that runs the CodeClimate scanning system. We published the following updates to the CodeClimate-based analyzer during the 16.1 release milestone:
Updated CodeClimate to version 0.96.0. This version includes:
A new plugin for golangci-lint.
A new available version for the bundler-audit plugin.
Added support for a configurable path to the Docker API Socket.
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.1 release milestone:
The Semgrep-based analyzer is updated to use version 1.23.0 of the Semgrep engine. We’ve also clarified guidance and improved efficacy of the GitLab-managed rules that are used to scan C, C#, Go, and Java. See the CHANGELOG for further details.
The SpotBugs-based analyzer now supports changing the “effort level” by setting the SAST_SCANNER_ALLOWED_CLI_OPTS CI/CD variable. This allows you to improve performance by reducing the scan’s precision and its ability to detect vulnerabilities. See the CHANGELOG for further details.
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 16.1.
Code suggestions (beta) is now available for self-managed instances
Code suggestions (beta) is now available for GitLab self-managed instances. When you use this feature, relevant source code is securely transmitted to GitLab’s infrastructure, which returns an AI-generated code suggestion. GitLab does not have any visibility into a self-managed customer’s code other than what is sent to generate the Code Suggestion. GitLab does not persist any customer code sent from the user, nor train on customer data. For more information, see our self-managed Code Suggestions blog post.
We will be provisioning access to this initial iteration of GitLab Code Suggestions on a customer-by-customer basis. Please comment on issue 415393 to request access, tagging your Customer Success Manager for help with enabling Code Suggestions once your instance is ready.
Geo has changed the workflow for proxying SSH Git push requests. Push requests made against a secondary site are now proxied via the GitLab shell (instead of Puma) to the primary site. The change removes the 1.0 GB push size limit that prevented large push requests from succeeding. The push size limit is now 1.86 GB which we will aim to remove in a future release. The new call flow through GitLab shell also increases throughput up to 50% in some cases. This is a behind-the-scenes change. No action is needed on your part.
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