Require multiple approvals from Code Owners
Require multiple approvals from Code Owners
You can now precisely define for which files, file types, or directories approval
has been designated as optional, required approval by one user, or by multiple users.
The latter being the new improvement of the CODEOWNERS
file.
So far, if you needed to require multiple approvers be it for compliance reasons or other reasons, you could only do so with an approval rule. However, unlike Code Owner approvals, approval rules apply to entire branches and cannot be refined to apply to specific parts of your code base. So, the multiple approvals would have also been required for changes that do not need a high level of scrutiny leading to unnecessary reviews.
Manage license approval policies
Manage license approval policies
GitLab now supports flexible license approval policies as the replacement for the deprecated License-Check feature. License approval policies improve the experience over the License-check feature in several ways:
- Users can choose who is allowed to edit license approval policies.
- Multiple policy rules can be created and chained together.
- A two-step approval process can be enforced for any desired changes to license approval policies.
- A single set of license policies can be applied to multiple development projects, or can be applied at the group or subgroup level, to allow for ease in maintaining a single, centralized ruleset.
- Policies can be used to require approval for any license that is not specifically allowed.
License approval policies can be used alongside the existing License-Check feature, as the two policies are additive and don’t conflict. To get started, verify that the license_scanning_policies
feature flag is enabled for your instance and then navigate to Security & Compliance > Policies, create a new Scan Result type policy, and select License scanning for your policy rule.
Notifications now available in the GitLab for Slack app
Notifications now available in the GitLab for Slack app
The GitLab for Slack app is the new home for managing notifications from GitLab to your Slack workspace. Not only can you use existing app features such as slash commands, but you can now also specify which Slack channels you want to notify based on merge request changes, push events, issue changes, and many other GitLab events.
The Slack notifications integration is now deprecated for SaaS customers and will eventually be removed as we continue to expand support for our GitLab for Slack app to better meet your needs. To keep your teams in sync with what’s happening in GitLab, get the GitLab for Slack app today!
Code Suggestions available in closed beta
Code Suggestions available in closed beta
Every day millions of developers use GitLab to contribute code. We’re starting to empower developers to code more efficiently and effectively with a closed beta of GitLab Code Suggestions.
Closed beta participants can use the GitLab Workflow VSCode extension to get code suggestions as they type. Depending on the prompt, the extension either provides entire code snippets like generating functions, or completes the current line. Simply pressing the tab key allows you to accept the suggestions.
Currently we support the following languages with the highest confidence: Python, C, C++, Java, Javascript, and Go.
GitLab Code Suggestions can improve developer productivity, focus, and innovation without context switching and within a single DevSecOps platform. While currently limited in closed beta, interested Ultimate customers can express interest by filling out this form to be considered for early access.
Track important incident timestamps on the incident timeline
Track important incident timestamps on the incident timeline
Incident metrics are a set of standard, quantifiable measurements used to track the incident response process. Accurately tracking these metrics will help DevSecOps teams understand how they are performing and whether responses to unplanned outages are getting better or worse. With this release, you can specify optional incident tags to capture relevant incident timestamps. Added tags are displayed next to the timestamp.
New License Compliance scanner
New License Compliance scanner
GitLab now supports a new method of detecting licenses that is capable of parsing and identifying over 500 different types of licenses and can extract license information from packages that are dual-licensed or have multiple different licenses that apply. In GitLab’s development testing, this has empirically resulted in dramatically improved accuracy and completeness of results. Fewer CI pipeline minutes are consumed because the License Compliance job is no longer required. Additionally the new method has support for the same languages and versions as GitLab Dependency Scanning.
To use this new scanner, remove the inclusion of the Jobs/License-Scanning.gitlab-ci.yml
template in your CI configuration and instead include the Jobs/Dependency-Scanning.gitlab-ci.yml
template. After GitLab 16.0, the old method of scanning with the Jobs/License-Scanning.gitlab-ci.yml
template will no longer be supported.
Currently this feature is available for GitLab SaaS users behind the license_scanning_sbom_scanner
and package_metadata_synchronization
feature flags. Users can follow along in GitLab to track the work to enable the license_scanning_sbom_scanner and the package_metadata_synchronization feature flags by default along with work to add support for self-managed instances and offline instances.
Secure your CI/CD workflows with OpenID Connect (OIDC)
Secure your CI/CD workflows with OpenID Connect (OIDC)
Your software supply chain should include everything needed to deliver and run your software. Securing that supply chain means securing not only your software, but also the surrounding cloud-native infrastructure as well.
In GitLab 15.9 we added additional layers of protection to move our OIDC token from Alpha to production-ready, increasing the security of your CI/CD workflows. A key improvement is the ability to configure the audience claim (aud:
), a reserved claim which identifies the audience the JWT is intended for (the target of the token).
Additionally, we increased the security of JWT tokens themselves. Previously, JSON web tokens were pre-defined variables that were made available to all jobs in a pipeline. In this release, you can now restrict the tokens from being available everywhere in the pipeline, and instead specify the exact jobs that need a token. As a result, the risk of a compromised job leaking a token is reduced.
Remove character limitations in unexpanded (raw) masked variables
Remove character limitations in unexpanded (raw) masked variables
Previously it was impossible to mask variables containing certain special characters, for example $
, '
, or "
. This sometimes prevented masked variables from being used for keys or passwords which typically contained one of those characters. In this release, we’ve removed that masking limitation for non-expanded (raw) variables. Note that the value still has an 8-character minimum length, and must not use spaces.
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