API endpoint to delete project topics
In a previous release, we added the ability to create and manage project topics that are used to categorize projects and find similar new projects. However, we did not create a way to delete them. In this release, thanks to Timo Furrer’s contribution, we added an API endpoint to delete project topics to make topic management more neat and efficient.
Display total time scatterplot on each value stream stage
In value stream analytics for groups, the Days to completion chart has been renamed to Total time. Instead of using the dropdown to view Total time data for a stage, you now select the stage from the top of the page.
New API endpoints for keys and tokens
GitLab 14.9 delivers new REST API endpoints:
- Return a single SSH key for a specified user. This is useful to enable GitLab SSH keys to be a
Terraform-managed resource.
- Return a single project’s deploy token by ID. This allows for a simple request to return a deploy token instead of
returning and sorting through pages deploy tokens with the API.
- Return a single group access token or project access token.
Thank you Timo Furrer for your contribution!
Notifications for new PATs and email addresses
Users want to be aware when new personal access tokens are created for and new email address are added to their account. In GitLab 14.9,
a user’s primary email address is sent a notification when:
- A new personal access tokens is created for their account.
- A new email address is added to their account.
This acts as an extra layer of security and can serve as a warning of suspicious activity.
Thank you Riccardo Padovani for your contribution!
Special characters not permitted in new project names
Project and Group names that have a leading or trailing special character breaks the container registry. As of this release, you can no longer use special characters as the first or last characters of new project or group names. You can still use special characters in any other part in the name. This ensures proper functionality within all stages at GitLab, and enhances the experience of our single platform tool.
Users can recover projects pending deletion
In previous versions of GitLab, only Administrators could see projects that were pending deletion.
With GitLab 14.9, all users can now view the Pending deletion tab. Project and group owners can view and recover projects that were accidentally deleted and
have not yet been permanently removed from disk. This means users can recover their own accidentally deleted projects without needing to direct all recovery
requests to an Administrator. To see the tab, on the top bar, select Menu > Projects > Pending deletion.
Render pasted Markdown in the wiki WYSIWYG editor
Markdown content destined for your GitLab wiki is sometimes created outside of GitLab. In the “classic” wiki editor, you can paste valid Markdown with no problem, because you are working with the raw source. The page only renders when you submit the content. In the wiki WYSIWYG editor, however, your clipboard’s content might have been pasted in as plain text, forcing you to manually reformat every line to remove Markdown syntax and re-format it using the WYSIWYG tools.
In GitLab 14.9, the Markdown content you paste into the WYSIWYG editor using Command / Control + V is parsed and rendered as rich text. You can still force the content to paste as plain text using Command / Control + Shift + V.
Artifact sizes are being recalculated
Because of previous statistics calculations, the total artifact sizes shown in usage quotas might be incorrect. To ensure artifacts sizes are
reporting accurately, we have added a background script on GitLab.com to automatically recalculate sizes.
You may notice artifact statistics will fluctuate to 0 at times while the script is recalculating. After recalculation, statistics will return
to normal.
Include the same CI/CD template multiple times
Previously, trying to have standard CI/CD templates that you reuse in many places was complicated because each template could only be included in a pipeline once. We dropped this limitation in this release, so you can include the same configuration file as many times as you like. This makes your CI/CD configuration more flexible as you can define identical includes in multiple nested configurations, and rest assured that there will be no conflicts or duplication.
ARM support for the GitLab agent for Kubernetes
The GitLab agent for Kubernetes now supports ARM32 and ARM64 architecture. This is an important step to provide support for cluster connections running on Apple M1 chips or in low powered environments like the Raspberry PI.
Permanent link to the latest version of a release
Prior to this update, to refer to the latest release of a project, users needed to know the exact version number. We have now added a link to the latest release for a project. This makes it much easier and more efficient to navigate to the latest release.
Provision a Kubernetes cluster from GitLab with Terraform
GitLab has deep integrations with Kubernetes for deployments and security. However, some users struggle with setting up an initial cluster with GitLab. The UI-based solution for this integration had several shortcomings and the configuration options were very limited.
You can now use an example project and related documentation to help set up a Kubernetes cluster using Terraform as the Infrastructure-as-Code methodology. This solution uses the GitLab agent for Kubernetes as the component that connects GitLab to your cluster. Using this example, you can create your own project and fully customize it for your needs. The example project provisions a cluster to Amazon Elastic Kubernetes Service (EKS) or Google Kubernetes Engine (GKE).
View GitLab agent for Kubernetes version in the UI
If you use the GitLab agent for Kubernetes, you must ensure that the agentk version installed in your cluster is compatible with the GitLab version. While the compatibility between the GitLab installation and agentk versions is documented, until now it was not very intuitive to figure out compatibility issues. To support you in your upgrades, GitLab now shows the agentk version installed on the agent listing page and highlights if an agentk upgrade is recommended.
Dependency Scanning adds support for Java 17
We have added support for Java 17 to Dependency Scanning. Thank you to community contributors @rpandini_wh and @gliDom for their assistance. If you are using the latest, or latest major (2), version of the container you do not need to do anything to receive this update. If you have pinned your container to a minor or specific version please update to at least 2.26.0 receive this update.
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 14.9 release milestone. These updates bring additional coverage, bug fixes, and improvements.
- Bandit analyzer updated to version 1.7.4. See CHANGELOG for details.
- Brakeman analyzer updated to version 5.2.1. See CHANGELOG for details.
- Add initial Rails 7 support
- Fix issues with rules
- Add checks for unsupported Ruby and Rails versions
- ESLint analyzer updated to version 7.29.3 of
eslint-plugin-react and new versions of various dependencies. See CHANGELOG for details.
- Add, fix, and update various rules
- Kics analyzer updated to version 1.5.3. See CHANGELOG for details.
- Fix various rules
- Improve IAM Policy evaluation
- Expand coverage of privileged-container Kubernetes rule
- MobSF analyzer updated to version 3.5.0. See CHANGELOG for details.
- Reduce severity of some existing rules
- PMD analyzer updated to version 6.43.0. See CHANGELOG for details.
- Secrets analyzer updated. See CHANGELOG for details.
- Semgrep analyzer updated to version 0.84.0. See CHANGELOG for details.
- Improve handling of global constants and Go raw string literals
- SpotBugs analyzer updated to version 4.6.0. See CHANGELOG for 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.
Geo accelerates static assets when using a unified URL
When Geo is configured to use a unified URL, secondary sites proxy requests back to the primary site when they can’t serve those requests locally.
In this release, static assets such as images are served directly by the secondary sites and are no longer proxied to the primary site. This may result in faster page load times for Geo users in remote locations.
GitLab chart improvements
Code Search for archived projects that are not indexed by Advanced Search
Previously, code from archived projects was not searchable by default if Advanced Search was enabled. Now, code search for archived projects falls back to basic search. For this to work, however, you must either search within the project or first select the project from the search results page.
Searching for issues across groups is now twice as fast
It could be slow to search across groups with many projects using Advanced Search. The slowness was caused by a lookup for each project in the group. Groups with many projects would take a long time to return results.
We now use inheritance, which makes these searches perform twice as fast.
API for Security & Compliance menu visibility
Previously, the Security & Compliance menu could only be enabled or disabled using the GitLab UI.
Thanks to a community contribution, GitLab now provides an API to allow users to enable or disable the Security & Compliance menu. To get started, see the
API documentation.
Filter group members by provisioned users
Prior to this release, you could have a mix of provisioned and non-provisioned users in groups, but there is no way to filter by this status to easily locate them. We have now added the ability to filter by the enterprise badge which is available to group owners.
You can now filter by the Enterprise user badge, making it easy to allocate the provisioned users in groups and projects with many members.
New audit events
The GitLab 14.9 release adds support for auditing the following activities:
- Creating a new merge request approval rule.
- Deleting a merge request approval rule.
- Approving a merge request. (Supported as streaming audit events only.)
- Creating, deleting, or revoking a project or group deploy token.
- Failed attempts to create a project or group deploy token.
- Authenticated git push or git pull commands to a private repository performed over either SSH or HTTPS (Supported as streaming audit events only.)
Parent-child support for compliance pipelines
In GitLab 14.8 (released February 22nd, 2022), we added support for compliance pipelines to use the trigger: keyword to initiate a child pipeline. This change will help organizations who choose to organize their jobs with parent-child pipelines.
Streaming audit events for MR approvals
You can now monitor merge request approval activity that happens on the merge requests in your groups and projects. You
can see which merge requests are being approved and by whom, if you need to refer back to that later.
Because of the volume of data we expect to be generated by these events, they are only
available as streaming audit events.
Shortcut to open related issue
When creating a new issue from another issue, an option to mark the two issues as related is selected by default. This handy shortcut enables you to create one or more related issues without having to remember or copy-pasting issue IDs.
Thanks for the contribution Steve!
Review previously merged commits in merge requests
The best code reviews take into account the broader context and impact of changes, including previously merged commits. But it can be challenging to bring that context into merge requests, so that everyone can discuss how the proposed changes align with older changes.
You can now stack previously merged commits onto the proposed changes in your merge request, to help you and everyone else understand the full context of the changes.
Thanks to Paulo Vitor Magacho, Anwar Sadath and Abhishek Kumar for all working to contribute this!
GitLab Runner 14.9
We’re also releasing GitLab Runner 14.9 today! GitLab Runner is the lightweight, highly-scalable agent that runs your build 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.
Specify variables when running manual jobs via the API
When running a manual job, it can be useful to input CI/CD variables to overwrite the existing variables, or to add new ones. Previously, the only way to do this, was to do it through the UI. In this release we’ve added the ability to specify variables when running a job by using the REST API, which will give you more options for automating your CI/CD pipelines.
Add comment when approving/rejecting a deployment
In this release, we have introduced an enhancement to deployment approvals. You can now leave an optional comment when reviewing a deployment, providing more context as to why the deployment was approved or rejected. This functionality is also useful for organizations in highly regulated industries that need to audit release events.
Persistent Volumes in Auto DevOps
Previously, when you deployed an application via Auto DevOps that requires Persistent Volumes, you had to create a custom chart repository. However, it was cumbersome to host a chart repository on your own due to the maintenance burden. In GitLab 14.9, you can create Persistent Volumes by specifying the persistence keyword in the configuration file.
Thank you Frank Brooks for your contribution!
Simplified migration to agent-based connections
If you have a certificate-based cluster that’s connected with GitLab, you can now use an agent-based connection at the same time. Previously, to migrate from a certificate-based connection to an agent-based setup, you had to complete additional steps, and the process was especially difficult for group and instance-level clusters. By presetting both Kubernetes contexts, migration is largely simplified. You can now select the context provided by the agent, instead of the default context that’s provided by the certificate-based connection.
Add text and links for incident metric images
During an incident, it can be challenging to capture and organize metrics. Starting in this release, users can add links and text to images of incident metrics. This makes it easier to reference metrics throughout the incident.
Dependency Scanning outputs CycloneDX documents
In order to align with a popular Software Bill of Materials (SBOM) industry format standard, Dependency Scanning’s gemnasium analyzers will now output a CycloneDX SBOM for each supported lock or build file detected. These CycloneDX SBOMs are named cyclonedx-<package-type>-<package-manager>.json, and are saved in the same directory as the detected lock or build files. The CycloneDX SBOMs can be downloaded the same way as other job artifacts.
UI option to enable Container Scanning
GitLab 14.9 now supports Container Scanning on the Security Configuration page. Security is a team effort and this configuration experience makes it easier for non-CI experts to get started with GitLab Container Scanning. The tool helps a user create a merge request to enable Container Scanning, while leveraging best configuration practices like using the GitLab-managed Container-Scanning.gitlab-ci.yml template. The Configuration tool can create a new .gitlab-ci.yml file if one does not exist, or update existing simple GitLab CI files. You can therefore use the tool with projects that already have GitLab CI set up. To get started, navigate to Security & Compliance > Configuration and visit the Container Scanning section.
Geo’s admin area supports secondary-specific actions when using unified URLs
When Geo is configured with a unified URL, system administrators would not be able to directly access secondary site specific replication details or perform actions in Geo’s administrator area. This was only possible when using the IP address of a secondary site directly or by setting up another domain name.
In 14.9, Geo supports viewing replication details and performing actions directly in the admin area without the need for a workaround. This change excludes Projects and Designs, which will be supported in a future iteration.
Omnibus improvements
- GitLab 14.9 includes Mattermost 6.4, with unlimited playbooks, and multiple Boards enhancements including standard templates, template previews, new archive format with image support, card badges, and GIF support. This version also includes security updates and upgrade from earlier versions is recommended.
- GitLab Spamcheck is now available in the Omnibus package. Spamcheck started as a GitLab internal project, however, it became clear that the community could benefit from these efforts, and the decision was made to strive towards making much of it public. Spamcheck allows users to detect, and mitigate the effects of spam.
Rate limiting added to Global Search
Some of the processes in Global Search conduct up to 10 queries per search. When there is a sudden rush of searches, this can slow performance and impact other parts of GitLab. To improve the overall stability of GitLab, we have added rate limits for Global Search. These rate limits are automatically enabled and are preset to the configurations used by GitLab.com.
The new search_rate_limit replaces the rate limit for user_email_lookup_limit. Consult the Important notes on upgrading to GitLab 14.9 section for details.
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