GitLab 16.1 released with all new navigation

Improved domain verification

Improved domain verification

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.

Password reset email sent to any verified email address

Password reset email sent to any verified email address

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.

Prevent user from deleting account

Prevent user from deleting account

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.

SCIM identities included in users API response

SCIM identities included in users API response

The users API now returns the SCIM identities for a user. Previously, this information was included in the UI but not the API.

View Vulnerability Report as Customizable Permission

View Vulnerability Report as Customizable Permission

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.

Configure the static file directory in GitLab Pages

Configure the static file directory in GitLab Pages

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.

Create a changelog from the GitLab CLI

Create a changelog from the GitLab CLI

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.

Thanks Michael Mead for your contribution!

CI/CD job token scope API endpoint

CI/CD job token scope API endpoint

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!

GitLab Runner 16.1

GitLab Runner 16.1

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.

What’s new:

• GitLab Runner Fleeting plugin for Azure Virtual Machines (Experimental). Thank you to vincent_stchu for this contribution!

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

Runner details - consolidate runners sharing a configuration

Runner details - consolidate runners sharing a configuration

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.

Issue URL placeholder in Service Desk emails

Issue URL placeholder in Service Desk emails

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.

Automatic response to leaked Google Cloud secrets

Automatic response to leaked Google Cloud secrets

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:

• Service account keys
• API keys
• OAuth client secrets

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.

See the blog post about this integration for further details.

Code Quality analyzer updates

Code Quality analyzer updates

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.
  • Thanks to @tsjnsn for this community contribution. Updates to include this variable in the CI/CD template are tracked in an issue.

See the CHANGELOG for further details.

If you include the GitLab-managed Code Quality template (Code-Quality.gitlab-ci.yml), you automatically receive these updates.

For Code Quality changes in previous releases, see the most recent update.

Shared ruleset customizations in SAST, IaC Scanning, and Secret Detection

Shared ruleset customizations in SAST, IaC Scanning, and Secret Detection

You can now set a CI/CD variable to share ruleset customizations for SAST, IaC Scanning, or Secret Detection across more than one project.

Sharing a ruleset can help you:

• Disable predefined rules that you don’t want to focus on in your projects.
• 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.

Backup adds the ability to skip projects

Backup adds the ability to skip projects

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!

Geo verifies Design repositories

Geo verifies Design repositories

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.

Omnibus improvements

Omnibus improvements

• GitLab 16.1 adds support for building and releasing packages on Debian 12 Bookworm that released on June 10, 2023.

More detail in completed GitHub project import summary

More detail in completed GitHub project import summary

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.

Personal access token last_used value updated more frequently

Personal access token last_used value updated more frequently

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.

Thank you Jacob Torrey for your contribution!

Reintroduction of OmniAuth Shibboleth support

Reintroduction of OmniAuth Shibboleth support

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.

Select administrator access for personal access tokens in Admin Mode

Select administrator access for personal access tokens in Admin Mode

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.

Thank you Jonas Wälter, Diego Louzán, and Andreas Deicha for contributing!

Add a description to design uploads

Add a description to design uploads

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.

Comment on whole file in merge requests

Comment on whole file in merge requests

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.

Beautify the UI of CI/CD pipelines and jobs

Beautify the UI of CI/CD pipelines and jobs

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.

CI/CD: Use needs in rules

CI/CD: Use needs in rules

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!

Increased storage for GitLab SaaS runners on Linux

Increased storage for GitLab SaaS runners on Linux

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.

Install npm packages from your group or subgroup

Install npm packages from your group or subgroup

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.

Show external user as a comment author in Service Desk issues

Show external user as a comment author in Service Desk issues

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.

Clearer guidance and better coverage for SAST rules

Clearer guidance and better coverage for SAST rules

We’ve updated the GitLab SAST rules to:

• 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.

SAST analyzer updates

SAST analyzer updates

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.

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.

Fail closed for invalid Security Policy approval checks

Fail closed for invalid Security Policy approval checks

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.

Geo adds filtering by replication status to all components

Geo adds filtering by replication status to all components

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 chart improvements

GitLab chart improvements

• 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.