Associate MRs to issues when migrating groups with projects
When migrating groups using GitLab Migration, GitLab now preserves associations of imported merge requests to issues. This populates the Related merge requests section
on the issue details page.
Import GitHub branch protection rules
When you import projects from GitHub to GitLab, GitHub branch protection rules that have an equivalent on GitLab are mapped to GitLab branch
protection rules or project-wide GitLab settings:
- GitHub rule Require conversation resolution before merging for the project’s default branch is mapped to the All threads must be resolved
GitLab setting.
- GitHub rule Require a pull request before merging is mapped to the No one option in the Allowed to push list of the branch protection
rule.
- GitHub rule Require a pull request before merging - Require review from Code Owners is mapped to the Code owner approval branch protection
rule. Requires GitLab Premium or higher.
- GitHub rule Require signed commits for the project’s default branch is mapped to the Reject unsigned commits GitLab push rule.
Requires GitLab Premium or higher.
- GitHub rule Allow force pushes - Everyone is mapped to the Allowed to force push branch protection rule.
New GraphQL parameter for analyzing deprecated schema items
You can now make calls against the GraphQL API as if all deprecated items were already removed. To make these calls, add the new remove_deprecated=true query parameter to the GitLab GraphQL API endpoint. This way, you can verify your API calls against the GraphQL schema without the deprecated schema items.
Prevent Guests from viewing internal notes
Internal notes provide organizations with a way to manage internal communication in an issue or epic. We have improved support for this use case by ensuring users with the Guest role cannot create or view internal notes on GitLab issues and epics, even if they are the assignee or the author for that issue or epic. This provides organizations assurance that information in their internal notes will only be visible to members of their organization.
Default split view for Markdown preview in the Web Editor
The ability to preview Markdown files side by side while editing was introduced in GitLab 14.2. With this release, we’ve made the split view the default experience for previewing Markdown in the Web Editor. In the Preview tab, you can now see a live Markdown preview that updates as you type alongside your content. This way, you can be confident that your markup is valid and renders as you intended without having to switch between the Write and Preview tabs.
Admin Area Runners - job queued and duration times
When GitLab administrators get reports from their development team that a CI job is either waiting for a runner to become available or is slower than expected, one of the first areas they investigate is runner availability and queue times for CI jobs. While there are various methods to retrieve this data from GitLab, those options could be more efficient. They should provide what users need - a view that makes it more evident if there is a bottleneck on a specific runner.
The first iteration of solving this problem is now available in the GitLab UI. GitLab administrators can now use the runner details view in Admin Area > Runners to view the queue time for CI job and job execution duration metrics.
Improved values support for Helm-based deployments
We shipped initial Helm-chart support for the agent for Kubernetes in GitLab 15.4. In that release, Helm values had to be included in the Helm charts, which caused large-scale code duplication for users.
This release allows you to specify the Helm values as part of the agent configuration by adding environment-specific values to the agent configuration file, and keeping generic values within the Helm chart.
Mount ConfigMap to volumes with the Auto Deploy chart
The default Auto Deploy Helm chart now supports the extraVolumes and extraVolumeMounts options. In past releases, you could specify only Persistent Volumes for Kubernetes. Among other use cases, you can now mount:
- Secrets and ConfigMaps as files to Deployments, CronJobs, and Workers.
- Existing or external Persistent Volumes Claims to Deployments, CronJobs, and Workers.
- Private PKI CA certificates with hostPath mounts to achieve trust with the PKI.
Thanks to Maik Boltze for this community contribution.
Show multiple approval rules in deployment approval UI
In this release, we are adding additional key information for multiple approval rules in the approval UI. Now during the workflow of approving a deployment, you can see who has already approved, as well as how many approvals are still needed and from which groups. This key information enables transparency and context for making the approval decision and also ensures compliance during an audit review.
Automatically add incident severity changes to incident timelines
Incident severity is assigned at the beginning of an incident to ensure proper response across the organization. Incident severity is determined based on the information available at the time. Severity should be adjusted as more information becomes available. In this release, changes in incident severity automatically appear in the incident timeline.
More accurate SAST rules for Python
The GitLab Vulnerability Research team has updated the rules used for Python SAST scanning to catch more relevant problems with fewer false-positive results.
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, existing findings we’ve identified as false positives will be marked “No longer detected”, and new findings may be created.
Static Analysis analyzer updates
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.6 release milestone. These updates bring additional coverage, bug fixes, and improvements.
- Gitleaks-based analyzer updated to version 8.15.0. See CHANGELOG for further details. This month, we also:
- Fixed the rule for Slack webhook URLs.
- KICS-based analyzer updated to version 1.6.2. See CHANGELOG for further details. This month, we also:
- Added new rules for CloudFormation and Terraform.
- Addressed several false positive detections in existing rules. Findings from these rules will be marked “No longer detected”.
- Changed the severity of some existing rules.
- Fixed an issue where Info-level findings were incorrectly mapped to Unknown severity.
- MobSF-based analyzer updated to version 3.6.0. See CHANGELOG for further details.
- PMD Apex-based analyzer updated to version 6.50.0. See CHANGELOG for further details.
- Semgrep-based analyzer updated to version 0.121.2. See CHANGELOG for further details.
- SpotBugs-based analyzer updated to version 4.7.3. 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.
For previous changes, see last month’s updates.
Scan execution policy support for dependency scanning
Users can now require Dependency Scanning to run on a regular schedule or as part of project CI pipelines, independent of the .gitlab-ci.yml file’s contents. This allows security teams to manage these scan requirements separately without allowing developers to change the configuration. You can get started by creating a scan execution policy on the Security & Compliance > Policies page.
Omnibus improvements
- GitLab 15.6 also includes Mattermost 7.4, with Calls keyboard shortcuts and multiple improvements to Boards including minimum default board roles, guest account support, and multi-person properties. This version also includes security updates and upgrading from earlier versions is recommended.
Display a summary of a user’s contributions before deletion
Previously, when you deleted a user and their contributions from the Admin area, it was not clear what and how many associated contributions were about to be deleted. Now, before proceeding with deleting a user, a confirmation message lists the number of groups, projects, issues, and merge requests associated with the user. This summary can help you prevent the accidental deletion of projects or subgroups.
Import pull request assigned reviewers from GitHub
Previously, while importing projects from GitHub to GitLab, reviewers assigned to pull requests in GitHub were not imported as reviewers assigned
to merge requests in GitLab.
With this release, assigned reviewers are imported as assigned reviewers in GitLab. The following are out of scope for this release:
- Review approval status.
- Reviews requested from teams.
New GraphQL API for Contribution Analytics
To help you analyze team contributions, we have now exposed the Contribution Analytics data through GraphQL. Using this new API, you can identify opportunities for improvement and gain insights into the top contributors in your team.
The Contribution Analytics report visualizes the team’s push events, merge requests, and opened or closed issues at a group level over time.
Configure default names for branches created from issues
Define a custom template for naming branches created from issues. The previous setting {issue ID}-{issue-title-hyphenated} remains the default. To define a custom template for your project, go to Repository Settings > Branch defaults.
Update access levels from Protected Branch API
Previously, the UI was required to update the access levels of protected
branches. The API required you to unprotect, then reprotect, a branch when
updating its access levels. Now, the
protected branches API
enables you to directly update which users or groups are allowed_to_push, allowed_to_merge,
allowed_to_unprotect, and more. This one-step method decreases the risk of a bot
changing this setting and leaving a branch unprotected.
GitLab Runner 15.6
We’re also releasing GitLab Runner 15.6 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:
Bug Fixes:
The list of all changes is in the GitLab Runner CHANGELOG.
Kubernetes 1.25 support
This release adds full support for Kubernetes version 1.25, released in August 2022. If you use Kubernetes, you can now upgrade your clusters to the most recent version and take advantage of all its features.
Read more about our Kubernetes support policy and other supported Kubernetes versions.
Publish releases without giving access to source code
Previously, granting access to releases for public projects also allowed access to the source code. With this update, you can now publish releases without giving access to the source code. This is useful for organizations that use releases as a way to give access to new versions of software but do not want the source code to be public.
Add linked resource to an incident with a quick action
Important links can end up buried in comments throughout your incident. We added linked resources in incidents in 15.3. In this release, you can use a quick action to add one or more linked resources to an incident.
Beta: Automatic revocation of leaked Personal Access Tokens
GitLab Secret Detection finds leaked credentials in your codebase so you can revoke them and protect your organization.
It detects many kinds of sensitive values, including GitLab Personal Access Tokens.
GitLab is dogfooding a new feature where Personal Access Tokens on GitLab.com are automatically revoked if Secret Detection finds them leaked on the default branch of a public repository.
We’ll roll this feature out across GitLab.com and Self-Managed instances in an upcoming release.
If you’re interested in testing this feature during its Beta period, please let us know by completing this form.
See multiple Code Quality scan reports per pipeline
GitLab Code Quality includes an MR widget, a pipeline report, and MR diff annotations to help you find and fix problems in your code.
Many tools, including code scanners and linters for technical documentation, can output results in Code Quality’s open report format.
Previously, you could only see results from a single scan in the pipeline report and MR diff annotations.
This made it harder to add custom scanning tools to your pipelines.
Now, all of the Code Quality views show results from all report artifacts saved in a pipeline.
This new feature is controlled by a feature flag that is now enabled by default in GitLab.com.
We plan to enable the flag by default in Self-Managed instances in GitLab 15.7.
GitLab chart improvements
- Cloud Native GitLab will replace
alpine-certificates behaviors with gitlab-base in 15.7. To prevent differential behaviors between Alpine and Debian, and increase consistency across containers, we are going to build the pattern on gitlab-base. This means operational service containers will share a common root layer, which provides an efficiency boost to Pod instantiation time. The user impact of this change is that we will be changing the image name and tags used. We will maintain a mirrored tag for a brief period.
- The GitLab Helm Chart will have a new major version release before the next major GitLab version, separate from the next major version as a whole. We are not sure when this next Helm chart major version will be released. Expect it no sooner than 2 milestones, and possibly longer. This was announced in 15.5. This major Helm chart release will require downtime, as we incorporate large updates and require manual intervention for upgrade paths.
Minimum required Git version is now v2.37.0
The minimum required version of Git is now v2.37.0. This newer version has a lot of changes that we, and other Git community members, have made that
provide a much better experience and resolve many issues, including:
- Improved replication speed in
git-fetch.
- Improvements to
git-cat-file which reduces the number of spawning processes needed.
- An update that fixes corruption in Git references using the new
core.fsync option.
- A bugfix for
git-update-ref which fixes flushing semantics so that we can properly lock references.
- Support for cruft packs.
-
A new feature to compute merges in bare repositories with git-merge-tree.
If you use a version of Git on your GitLab instance that is not bundled with GitLab, please ensure you upgrade to at least v2.37.0.
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