JiHu GitLab 15.9 released with new guest roles for viewing private repositories and license approval policies
JiHu GitLab 15.9 released with new guest roles for viewing private repositories, license approval policies, notifications in the JiHu GitLab for Slack app, a new code suggestions closed beta and much more!
These are just a few highlights from the 105+ improvements in this release. Read on to check out all of the great updates below.
We thank the wider JiHu GitLab community for the 410+ contributions they provided to JiHu GitLab 15.9! At JiHu 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 15.10 release kickoff video.
Key improvements released in JiHu GitLab 15.9
Users with the Guest role can view private repositories
Users with the Guest role and an Ultimate license can now view private repository content if their administrator gives them permission. Administrators must create a new role through the API, and assign that role to users who the administrator wants to have view repository permissions. Previously, users with the Guest role could not view code in private projects, limiting their utility.
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.
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.
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!
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.
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.
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.yml template in your CI configuration and instead include the Jobs/Dependency-Scanning.yml template. After GitLab 16.0, the old method of scanning with the Jobs/License-Scanning.yml template will no longer be supported.
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.
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.
Users with the Owner role for a group can now use the GraphQL API to change the maximum access level of non-inherited users of a group. This release brings more administrative features to users with the Owner role for groups on GitLab.com, and lays the foundation for future administrative bulk actions.
Previously, in the Explore Projects tab of the Projects dashboard you could filter projects by name. Now, you can also filter by programming language. By applying this filter, you can narrow down the search results to projects that use only the programming language you’re interested in. This way you can find an open-source project in your favorite programming language to contribute to.
Previously, when a user lost access to their two-factor authentication (2FA), that user had to ask GitLab support to reset their 2FA. Now, group owners are able to disable 2FA for enterprise users. After a user’s 2FA is disabled, that user is prompted to set it up again.
It can be challenging to retrace your own activity across GitLab. You can view your contributions calendar or the Activity page of your projects, but it is not filtered to just your contributions.
In this release of GitLab, we’ve added a new default tab to the Activity page within the Your work section called Your activity. This gives a focused place to see your contributions in one place and filter by type of activity. You can view your push events, merge events, issue events, comments, wiki, designs, and team. This makes it easier to keep track of your work in GitLab.
The SCIM API now returns the :active attribute for each user. Group Owners can now use this attribute to distinguish between active and inactive users, which is useful as a user can be outside of their group, but still have a SCIM identity.
Teams often use Markdown checklist items to outline tasks or completion
criteria for an issue, but tracking more in-depth information related to the checklist item has always been limited and cumbersome. With the release of 15.9, you can seamlessly convert a Markdown checklist item in an issue to a task, enabling teams to have a more robust experience tracking and managing an issue’s dependencies by assigning and estimating tasks separately from issues.
Until now, epics could only contain sub-epic children from the same group. This was limiting and inconvenient for users who are trying to manage, organize, and communicate on large scale projects that have different sub-initiatives in other groups.
As a continuation of improving cross-functional workflows, you can now add child epics from unrelated groups to a parent epic.
Previously, you could view the performance of DORA metrics over the last week, month, and 90 days. Now, you can view it over the last 180 days as well. This new 180-day visualization allows software leaders to track quarterly metrics improvements and identify historical trends in their DevOps performance.
The CI/CD job token stored in the CI_JOB_TOKEN CI/CD variable makes authenticating API calls within jobs more intuitive, enabling advanced automation. For example, the token can be used with bot automation projects that run pipelines in other projects. The token is short-lived, but has the same permissions as the user that triggered the pipeline.
In an effort to make its usage even more secure we are adding a setting that lets you define a list of trusted projects that you allow to use job tokens to access your project. This added layer of security means that only these projects will be able to access your project’s API with a job token. In the bot automation example, it lets you control which bot projects can interact with your own project.
This setting is currently disabled by default in existing projects to avoid impacting pipelines, but we strongly recommend enabling it in all your projects. It is enabled by default for all new projects.
To create a consistent runner experience across admin, group, and project views, the group runners details view now includes a list of past and current jobs that the runner runs.
Among other details, you can see the job duration, as well as how much time each job was in queue before it was picked up by the runner. Having an overview of the
queued duration can help you further analyze the runner’s queue performance.
GitLab Secret Detection now automatically revokes GitLab personal access tokens if they’re found on the default branch of a public project.
To activate this protection, you need to use GitLab Secret Detection in the project and use tokens that are prefixed with glpat-.
We previously offered this feature as part of a Beta release and enabled it by default on GitLab.com on 2023-01-23.
The feature flag has been removed, so the feature is also active in self-managed instances starting in GitLab 15.9.
Leaked tokens are processed on the same system where they’re found: tokens detected on GitLab.com stay on GitLab.com and tokens detected in self-managed instances stay on those instances.
Due to technical limitations, GitLab Secret Detection previously scanned only the latest commit on branch pipelines.
Now, when Secret Detection runs in a merge request (MR) pipeline, it scans all of the MR’s commits so you can catch leaks made in earlier commits.
This improvement builds on recently-added support for security scanning in MR pipelines, so it’s only available in the Latest version of the Secret Detection CI/CD template, not the Stable version.
You can enable this new feature now by switching to the Latest version of the Secret Detection CI/CD template.
We plan to update the Stable templates with this change in GitLab 16.0.
Note that Latest templates can receive breaking changes in any release.
To learn more about Stable and Latest templates, see documentation on CI/CD template versioning.
You can now more easily stop and clean up stale environments in your projects. Using the API or UI, you can stop all environments that have not been modified since a specified date, excluding protected environments. You can use this to manage the number of environments in your project and keep only the relevant environments in the project.
The first iteration of showing related tags for a deployment only supported completed deployments. With this release, you can now see tags for deployed commits in the Environment page for deployments that are pending approvals as well. This information helps provide the people involved in executing and approving the deployment with more context about what is being deployed.
You can now add custom text to the email sent to a user when they are deactivated. You can customize this text in the Admin application settings. Previously, you could not change the text in this email.
Previously, it was not possible to import projects from external providers more than once.
Now you can import projects from external providers many times using different target paths.
The re-imported project doesn’t override or merge with previously imported project.
External providers include GitHub, Bitbucket Cloud, Bitbucket Server, FogBugz, and Gitea.
While using GitLab, you may have noticed that some pages don’t have a left sidebar. These pages are primarily user-orientated pages such as your assigned items (issues, merge requests, and to-do items) as well as pages related to your work environment such as groups, projects, and activity. Not having a left sidebar on those pages creates some inconsistency and layout shifting within GitLab.
In this release, we’ve added a new Your work sidebar to add consistency and a dedicated place in our navigation for the things you are working on.
This new sidebar paves the way for our navigation redesign, where the top navigation will move into the left sidebar.
You can now filter epic lists and roadmaps to show epics from a specific group. This makes it more efficient and flexible to target the information you need.
Within the roadmap view, we provided limited context about the epics displayed which makes it difficult for users to identify information without leaving the roadmap view. This feature will display assigned labels on the epic list in the sidebar, providing easy access and visibility without leaving the page. In addition, the ability to turn the feature off will be available in roadmap settings.
Quick actions are helpful for efficiently updating issues, merge
requests, and epics. With this release, you can now use a subset of quick actions when editing a task’s description. Future iterations will introduce additional quick actions and the ability to use them in comments in a task.
gitlab-sshd is a standalone SSH server, written in Go, that provides more insight
and control than OpenSSH. It’s lightweight and contains minimal external dependencies.
If you host a self-managed instance, switching from OpenSSH to gitlab-sshd gives you
metrics collection, detailed logging, and graceful shutdowns for SSH connections.
Unlike OpenSSH, it supports the PROXY protocol and can pass on the original IP address
when operated behind a proxy. This enables you to restrict SSH access by IP address
when your instance is operated behind a proxy.
GitLab.com has used gitlab-sshd since 15.2,
and 100% of the SSH traffic passes through gitlab-sshd. To learn more, read
this blog post.
To understand how to enable it refer to the documentation.
gitlab-sshd began as a community contribution from @lorenz.
Thank you very much for your contribution!
We’re also releasing GitLab Runner 15.9 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.
Have you been thinking about moving your npm registry to GitLab but haven’t been able to invest the time in planning a migration? GitLab is proud to announce the MVC launch of an npm package importer. You can now create a config.yml file that defines the packages you want to import from any npm compliant registry into GitLab, such as Artifactory. Then you add the importer to a .gitlab-ci.yml pipeline configuration file, and the importer does the rest. It runs in the pipeline, dynamically generating jobs that import all the packages into your GitLab package registry.
We’ve added new rules to GitLab SAST for Go, Java, JavaScript/TypeScript, and Python.
The new rules add better protection against potential SQL injection, resource exhaustion, and directory traversal vulnerabilities, and identify insecure configurations in common libraries.
The updated rules are included in the latest release of the Semgrep-based SAST analyzer.
If you use the default GitLab-managed CI/CD template for SAST on GitLab 15.0 or higher, your pipelines automatically update the Semgrep-based SAST analyzer to use the new rules.
On your first scan after the update, new findings may be created for these new rules.
GitLab Static Analysis includes many security analyzers that the GitLab Static Analysis team actively manages, maintains, and updates. The following analyzer updates were published during the 15.9 release milestone. These updates bring additional coverage, bug fixes, and improvements.
KICS-based analyzer updated to version 1.6.7. See CHANGELOG for further details. This version includes new rules, bug fixes, and improvements.
Kubesec-based analyzer updated to version 2.12.0. See CHANGELOG for further details.
PMD Apex-based analyzer updated to version 6.53.0. See CHANGELOG for further details.
Secrets analyzer updated to version 8.15.2. See CHANGELOG for further details. This version also improves the detection rule for Google Cloud service account keys.
Semgrep-based analyzer updated to improve debug logging. See CHANGELOG for further details.
If you include the GitLab-managed SAST template (SAST.gitlab-ci.yml), you don’t need to do anything to receive these updates. However, if you override or customize your own CI/CD template, you need to update your CI/CD configurations.
To remain on a specific version of any analyzer, you can pin to a minor version of an analyzer. Pinning to a previous version prevents you from receiving automatic analyzer updates and requires you to manually bump your analyzer version in your CI/CD template.
You can now allow the person who triggered a deployment pipeline to also approve the deployment to a protected environment. This is useful in emergency situations or for teams where users are allowed to deploy to special environments like production on their own.
GitLab Service Desk makes it easy to interact with customers and provide support.
To ensure that customer email addresses are kept private, you now need to have at
least the Reporter role in a project or group to see the sender address of a Service Desk issue.
This applies to both public and private projects.
