JiHu GitLab 15.11 released with project compliance frameworks report management at the group level, re-running downstream pipeline trigger jobs, vulnerability dismissal reasons, and much more!
These are just a few highlights from the 110+ improvements in this release. Read on to check out all of the great updates below.
We thank the wider JiHu GitLab community for the 180 contributions they provided to JiHu GitLab 15.11! 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 16.0 release kickoff video.
The Web IDE Beta brings powerful new capabilities and dramatically improved performance to the web-based code editor. The Web IDE Beta has been available for self-managed instances since GitLab 15.7, but was disabled behind a feature flag.
From GitLab 15.11, the Web IDE Beta is now the default editor for all self-managed instances. You can opt out of the Web IDE Beta any time in your user preferences.
Using achievements, users can now acknowledge the accomplishments of others and reward the effort and skill that they have demonstrated. You can now receive achievements for your contributions on GitLab, and display them on your user profile. An achievement consists of a name, a description and an avatar. Users with the Maintainer or Owner role can create custom achievements, award them to users meeting the achievement criteria, and revoke them if they no longer meet the criteria. Up to three of your most recent achievements will display underneath your profile image on your user profile page. If you prefer not to display achievements on your profile, you can opt out in the user profile settings.
In 15.11, we are releasing a Beta of this capability behind a feature flag. If you want to try it out on self-managed GitLab, ask your administrator to enable it. For GitLab.com, please request access in the feedback issue 405153.
We hope that this change will increase productivity and engagement in organizations, and motivate team members to showcase their skills and accomplishments. Please share your experiences in issue 405153.
Prior to GitLab 15.11, if you wanted to add or remove a compliance framework from a project, you needed to go to each project individually to
manage which framework was associated with the project. When managing more than a few projects, this process was tedious and inefficient.
Now, you can manage which compliance frameworks are applied to your projects at the group level, significantly reducing the amount
of time needed to make sure your projects are adhering to the regulations and standards you are measured against.
In GitLab 15.10, you could view all the projects in your group and see which ones had compliance frameworks applied to them. In GitLab 15.11, you can
add or remove compliance frameworks directly from the compliance frameworks report.
In previous releases, you had to manually add a comment to specify why a vulnerability was dismissed.
In GitLab 15.11, you can add a reason for dismissing a vulnerability to the Vulnerability Report.
Now you can quickly and consistently track why vulnerabilities were dismissed.
This feature is only available on GitLab.com. Support for self-managed instances is tracked in this issue.
This new dashboard provides strategic insights into metrics that help decision makers to identify trends and patterns to optimize software delivery. The Beta release is focused on measuring software development (DORA4) and the flow of value delivery (Value Stream Analytics) across projects and groups.
Organizations can use the Value Streams Dashboard to identify workflow inefficiencies and opportunities for improvements by benchmarking key DevSecOps metrics.
The Value Streams Dashboard offers visibility across every step of the software development lifecycle, without needing to buy or maintain a third-party tool.
Previously, if you needed to trigger a rerun of an entire downstream pipeline, you had to rerun the full upstream pipeline. This could be a time-consuming and inefficient process, especially if the upstream pipeline has many jobs or other downstream pipelines.
In this release, we’ve added the ability to rerun just the downstream pipeline, without having to re-run the entire parent pipeline, by selecting Run again on the trigger job. The newly triggered downstream pipeline replaces the original downstream pipeline in the pipeline graph. This will save you time and resources when you want just the downstream pipeline to run again.
Previously, if you wanted to change the behavior of included CI/CD configuration, like a CI/CD template, you may have used global CI/CD variables.
However, using global variables applies to the entire pipeline, not just the included configuration, which was not always desirable.
This release adds the ability to declare mandatory or optional input parameters for each includable configuration file.
These input parameters replace the need for global variables and are scoped to the included configuration only, having no impact on the rest of the pipeline.
This allows you to build more robust and isolated CI/CD templates, as well as declare and enforce constraints. Learn how to use CI interpolation in this example repo.
GitLab group and project migration by direct transfer requires that both GitLab instances have the feature enabled in application settings by
an instance administrator. Until now, if you tried to initiate an import when the feature was disabled on the source instance, you received a 404
error.
We’ve replaced the 404 error with an informative message, and provided guidance on how to enable the feature.
In GitLab 15.11, we have improved syncing of both existing and new data between Jira Cloud and the GitLab for Jira Cloud app.
Previously, when you added a namespace to the GitLab for Jira Cloud app, only existing merge request data was synced to Jira. Now, existing branch and commit data is also synced.
When you viewed a Jira issue, the GitLab for Jira Cloud app previously showed related GitLab branches only if the branch name contained the Jira issue ID (for example, my-branch-JIRA-1). The GitLab for Jira Cloud app now also links to GitLab branches when you mention the Jira issue ID in the merge request title or description.
You can now configure LDAP synchronization to not include the user’s name. Previously, LDAP synchronization always included this information, making it impossible to change the name value in GitLab. This option is disabled by default.
The Web IDE Beta allows you to review merge requests and make additional changes to new and modified files without cloning the project to your local machine. However, when launched from a merge request, the Web IDE Beta previously didn’t open any of these files.
To make it easier to contribute, new and modified files now appear in separate tabs when you open the Web IDE Beta from a merge request. Each file is presented with inline diffs so you can review the changes immediately. To optimize performance, the Web IDE Beta only opens the top 10 files (by number of lines changed) in a merge request. In the file tree, any new or modified file is indicated by an icon next to the filename.
If you leak a secret in a public project, it’s important to remediate it as soon as possible. Otherwise, an adversary can abuse your account.
GitLab Secret Detection automatically responds to some types of credential leaks in public projects by revoking the credential or notifying the partner who issued it.
Previously, this automatic protection only worked after you committed the secret on the default branch.
Now, merge requests and other unmerged branches in public projects are also protected by the same automatic response.
Thanks to a community contribution from Weyert de Boer, GitLab Dependency Scanning now supports analyzing JavaScript dependencies managed by the pnpm package manager.
GitLab Dependency Scanning now supports analyzing dependencies defined in Yarn v2 and v3 lock files. This is currently limited to the dependencies downloaded from npm registries. Other protocols available in Yarn are not supported.
GitLab 15.11 adds documentation to help you configure the agent for Kubernetes when GitLab runs with a CI/CD integration and custom certificates. The documentation includes steps to set up KAS and agentk, and to invoke kubectl commands from GitLab CI/CD.
This release adds full support for Kubernetes version 1.26, released in December 2022. If you use Kubernetes, you can now upgrade your clusters to the most recent version and take advantage of all its features.
GitLab 15.11 includes Mattermost 7.9. This version includes
security updates so you should upgrade from earlier versions.
In GitLab 16.0, the minimum supported version of PostgreSQL will become 13. Therefore, in 15.11 we will swap attempt_auto_pg_upgrade? to true. This function will attempt to automatically upgrade the version of PostgreSQL to 13 in 15.11 in preparation for the new minimum PostgreSQL requirement in 16.0. This is the same behavior we performed in preparation for the last minimum upgrade of PostgreSQL.
In previous versions of GitLab, administrators needed to directly access the file system that stored a repository to add custom Git server hooks.
Now, administrators can set Git server hooks for a repository using the new the hooks set command in the Gitaly CLI. The Gitaly CLI command targets an individual Gitaly
node and applies the provided custom Git server hooks to the specified repository. You can use this to programmatically roll out Git server hooks across repositories in Gitaly.
All existing Git server hooks continue to function. However, hooks set is the only way to configure new Git server hooks in GitLab 15.11 and later.
hooks set does not yet work for Gitaly Cluster, but this effort paves the way for us to automatically replicate Git server hooks in Gitaly Cluster. Please follow that
effort in issue 5018.
Previously, when a user selected a non-public GitLab link, the link preview did not work due to the lack of OpenGraph and Twitter meta HTML tags for the sign-in page. These tags have been added, and now the preview is visible when a user selects a non-public GitLab link.
Until now you could migrate GitLab projects by direct transfer only when migrating GitLab groups. If some projects failed to be migrated, you couldn’t
try to import only failed projects again. The workaround was to import chosen projects by uploading export files, which imports only
one project at a time.
With this release, you can migrate projects by direct transfer using the API. You can use this to re-import only the chosen failed project. This also
lays the groundwork for this feature to be made available in the UI.
We updated the Value Stream Analytics overview and replaced the Total time line chart with a stacked area chart. The new chart displays a breakdown of all stages, with the time items spent in each stage over a selected time period. This visualization simplifies the top-down optimization flow from the Value Streams Dashboard to Value Stream Analytics, and helps you evaluate the progress of each stage at a glance.
Have you been thinking about moving your NuGet registry to GitLab, but haven’t been able to invest the time to plan the migration? GitLab is proud to announce the MVC launch of a NuGet package importer. You can now use the Packages Importer tool to import packages from any NuGet compliant registry, like Artifactory.
To use the tool, simply create a config.yml file that contains the details of the packages you want to import into GitLab. Then add the importer to a .gitlab-ci.yml pipeline configuration file, and the importer does the rest. It runs in the pipeline, dynamically generating a child pipeline with jobs that import all the packages into your GitLab package registry.
To align with a popular Software Bill of Materials (SBOM) industry format standard, the Container Scanning tool now outputs a CycloneDX SBOM for the scanned image. This CycloneDX SBOM is named gl-sbom-report.cdx.json and is saved in the same directory as the JSON report file. You can download CycloneDX SBOMs the same way as other job artifacts.
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.11 release milestone. These updates bring additional coverage, bug fixes, and improvements.
CodeClimate analyzer updated to version 0.94.0. See CHANGELOG for further details.
Brakeman-based analyzer updated to version 5.4.1. See CHANGELOG for further details.
KICS-based analyzer updated to version 1.6.13. See CHANGELOG for further details.
KubeSec-based analyzer updated to version 2.13.0. See CHANGELOG for further details.
Secrets analyzer updated to version 8.16.2. See CHANGELOG for further details. We also added new rules:
Security Code Scan-based analyzer updated to add support for .NET 7 by default. See CHANGELOG for further details.
Semgrep-based analyzer updated to version 1.17.1. We also fixed a parsing error related to Go false positive detection. See CHANGELOG for further details.
Thanks to @jnoordsij for this community contribution.
Sobelow-based analyzer updated to version 0.12.2. 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.
When you create an issue, propose a merge request, or write a comment, you might accidentally post a sensitive value.
For example, you might paste in the details of an API request or an environment variable that contains an authentication token.
Now, GitLab checks if the text of your issue, merge request description, comment, or reply contains a token.
If a token is found, a warning message is displayed. You can then edit your message before it’s sent to the server to be posted.
This new protection is always on; you don’t have to set it up.
Currently, it checks for GitLab Personal Access Tokens (PATs) and Feed Tokens.
Further improvements are considered in issue 405147.
If you follow continuous delivery practices using GitLab approval rules, previously you had to pick between Multiple approval rules
and Unified approval rules. Multiple approval rules are generally more flexible, but in past releases were only available through the API.
Approval rules settings pages now configure
multiple approval rules.
Previously, README files were available only at the project level. Now, they’re available at the group level too. As a group owner or member, you can use a README to provide more information about your team and invite users to contribute to your projects. In your group overview, selecting the Add README action creates a new project (gitlab-profile) that contains the README.md file. The README is displayed on the group overview page, and can be changed in the group settings.
