Allow updates to attributes for SAML or SCIM users
In previous versions of GitLab, we supported the project_limit and can_create_groups attributes only on newly SAML provisioned users. If users were created using SCIM or is updated in the SAML provider with these attributes, the project_limit and can_create_groups values would not be updated.
Now, if a user is created using SCIM or has an update to these attributes in the SAML provider, these sync to GitLab. This allows the identity provider to act as the single source of truth for core user attributes.
Automatically unblock LDAP users when signing in with other providers (SAML, OAuth, OmniAuth)
Transient LDAP errors can cause users to be blocked and unable to log in. If the transient error is resolved, GitLab now rechecks
LDAP and unblocks them if another authentication method (such as SAML or OAuth) is configured and used as the sign-in method and the user was blocked using LDAP.
Include Minimal Access role in SAML Group Sync
Administrators can now specify SAML Group Links with a minimal access role only for the top-level groups. This allows administrators to enhance security by defaulting to minimal access when the user is provisioned and assign more permissive roles at the sub-group level.
Topics selection in project settings
In this release, thanks to Jonas Wälter’s contributions, adding topics in project settings is easier than ever. Previously, to add a topic, you had to manually enter each topic and multiple topics had to be comma-separated.
Now you can select multiple topics from a dropdown list, making topic selection efficient and more convenient.
Git fetch resource optimizations
We improved the performance of traffic between Workhorse and Gitaly, resulting in git fetch now using fewer GitLab server resources. This change can cause issues on self-managed GitLab if a gRPC proxy is deployed between Workhorse and Gitaly. If you deployed a gRPC proxy between Workhorse and Gitaly, Workhorse can no longer connect. As a workaround, disable the temporary workhorse_use_sidechannel feature flag. If you need a proxy between Workhorse and Gitaly, use a TCP proxy.
Merge commit message template
Merge commits can provide important context to the commit history of a project about what was merged. However, if you don’t edit the merge commit prior to merging, other users are forced to navigate to a merge request to gain additional context about why the changes were made.
Project maintainers can now configure a default merge commit message template. This allows projects to specify a standard merge commit, and use variables to provide additional details in these messages. This additional context helps the next developer when trying to understand why the change was made, by providing the potential to make all the relevant information available in the merge commit.
Thanks to Piotr for this amazing contribution!
Tables in wikis support block-level elements
GitLab 14.1 introduced WYSIWYG editing for tables in the new wiki editor, but the types of content supported in table cells were limited by the underlying Markdown implementation: you couldn’t add block-level elements like lists, code blocks, or pull quotes inside a table. Now, in GitLab 14.5, these block-level elements are fully supported inside table cells. You can insert lists, code blocks, paragraphs, headings, and even nested tables inside a table cell, giving you more flexibility and freedom to format your content to meet your needs.
Add pipeline mini graph to the pipeline editor
Tracking the status of a running pipeline can involve significant context switching because you sometimes have to stop what you are doing to go check the pipeline page. Previously, the pipeline editor only showed the overall pipeline status and provided a link to the pipeline. In this release, we are adding the pipeline mini graph to the pipeline editor to make it easier for you to see the status of individual jobs without leaving the editor.
Improved UI for runners in the Admin Area
Previously, if you were a GitLab administrator, you could not easily find runners by instance, group, or project. The search and filter limitations made it difficult and inefficient to locate a runner when troubleshooting CI/CD job execution issues.
This release includes an initial update to the Runners page (Admin Area > Runners). The new layout helps you find runners more quickly and enables GitLab to provide future improvements for runner fleet management. The key improvements in this redesign are tabs that filter the list of runners by type, and indicators that show runners that have not recently connected to GitLab.
CI/CD Tunnel support for Omnibus installations
The CI/CD Tunnel support for self-managed instances installed through GitLab Charts was introduced in 14.0 and significantly improved since then. In this release, we are adding support for Omnibus installations.
The CI/CD Tunnel provides a secure connection from within GitLab CI/CD to your Kubernetes clusters using the GitLab Agent for Kubernetes. This enables users to continue using their existing tools and processes, and adopt the Agent for a robust and safe setup.
Basic authentication for alert HTTP endpoints
In the past, you needed a bearer token to authenticate to an alerts HTTP endpoint. Beginning with this release, you can also authenticate with Basic HTTP authentication, either through the headers or in the URL.
Return alert ID in POST responses for alerts
Currently, when you POST an alert using the generic alert HTTP Endpoint the response is a simple 200 upon a successful POST. If you want to reconcile your current alert workflows, you may need to see additional information returned in the POST response. In this release, we added the alert ID (iid) to the response, enabling you to see your specific alerts by a unique ID.
Static Analysis analyzer updates
GitLab Static Analysis is comprised of a set of many security analyzers that the GitLab Static Analysis team actively manages, maintains, and updates. Below are the analyzer updates released during 14.5. These updates bring additional coverage, bug fixes, and improvements.
- semgrep updated to version 0.72.0 - MR, Changelog
- various bug fixes for timeouts, crashes, and rule corrections. See changelog link for more details.
- flawfinder internal packages updated to version 2.14.7 - MR, Changelog
- gosec updated to version 2.9.1 - MR, Changelog
- Fix the SBOM generation step in the release action
- Phase out support for go version 1.15 because current ginko is not backward compatible
- sobelow internal packages updated - MR, Changelog
- We thank @rbf for their contributions (1,2,3) to our Sobelow analzer which enables new detection rules, and opens up the door for future improvements and additional rules in the future.
- PMD updated to version 6.40.0 - MR, Changelog
- Apex language support to v54.0
- Various improvements and bugfixes for rulesets.
- spotbugs updated to version 4.5.0 - MR, Changelog
If you include the GitLab managed vendored SAST template (SAST.gitlab-ci.yml) you do not need to do anything to receive these updates. However, if you override or customize your own CI template, you need to update your CI 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 require you to manually bump your analyzer version in your CI template.
Omnibus improvements
- With CentOS 8 EOL approaching, we have added support for AlmaLinux as a replacement in GitLab 14.5. AlmaLinux is backed by a company with a long track record of building an enterprise Linux compatible distribution and has the processes in place to sustain it. This aligns to our preference for the boring solution.
- GitLab will now publish an ARM64 version of GitLab Enteprise Edition to the AWS Community AMI catalog. AWS is seeing a rise in adoption of AWS Graviton2 (ARM64), so we want to make sure GitLab EE will be usable for those users accessing the AWS Community AMI catalog. This documentation contains relevant information for using the AWS community AMIs.
- GitLab 14.5 will provide packages for openSUSE Leap 15.3. OpenSUSE Leap 15.2 will reach its end of life on December 31st, 2021, therefore we want to provide OpenSUSE 15.3 in advance so users have a few milestones to make the move to a more recent version of OpenSUSE.
Audit events for group SAML configuration changes
GitLab now records audit events for changes to additional group SAML settings. Events are created when changes are made to:
- Enabled status
- Enforcing SSO-only authentication for web activity
- Enforcing SSO-only authentication for Git and Dependency Proxy activity
- Enforcing users to have dedicated group-managed accounts
- Prohibiting outer forks
- Identity provider SSO URL
- Certificate fingerprint
- Default membership role
- SSO-SAML group sync configuration
These events give you visibility on who configured or changed group SAML settings, and when. They can be used in
an audit to show that controls were correctly set and then never changed, or they can identify any changes that were
made that need to be further examined.
Contribution calendar aligned to configured timezone
Previously, your contribution calendar was aligned with the server’s timezone instead of your local timezone. Large differences between the two timezones could make it appear that you contributed a day earlier or later than you actually did.
Now, contribution calendars are aligned with your local zone, if set. Others can hover over activity to view your local date and time information, to compare their local timezone with your own.
Thanks to Dave Barr for this contribution!
Manage project topics with the API
In this release, thanks to Jonas Wälter’s contributions, adding topics in project settings is easier than ever. In addition to the latest project topic management features in the UI, you can now use the API to retrieve topics by list or ID. We’ve also made it possible for administrators to create or edit topics through the API. This introduces full parity between project topic management in the UI and API.
VSA deep link for URL query parameters
In previous releases we added the ability to filter Value Stream Analytics by attributes such as labels, milestones, and assignees. In this release, we’ve enhanced this by adding deep links for query parameters. This creates a hyperlink from the custom query that you can send as a URL to your peers for collaboration, or save as a bookmark for future use.
GitLab Workflow authentication with environment variables
In automated development environments, like Gitpod, configuration of GitLab Workflow for Visual Studio Code requires loading the editor and then setting the personal access token for GitLab each time. This process is time consuming, error prone, and leads to multiple or duplicate use of access tokens.
With the release of GitLab Workflow v3.36.0 the extension now supports configuration via environment variables. Using environment variables enables you to configure the authentication once. Each VS Code instance is then able to authenticate even when the previous VS Code instance has been deleted.
Sticky toolbar when editing wiki pages
When you edit long wiki pages, the editor grows vertically to fit your content. In previous versions, the editor could become so long that the formatting toolbar icons disappeared. When writing in raw Markdown, this can be frustrating but you can overcome it using keyboard shortcuts. However, the toolbar is a much more critical component of the new rich Markdown editor, so having this UI unavailable on the screen requires you to scroll vertically, away from your content, to access core features.
Now, in GitLab 14.5, the formatting toolbar remains fixed at the top of the input field, allowing you easy and persistent access to these convenient features, even when editing very long documents.
Thank you Mehul Sharma for contributing this helpful improvement!
View file tree when reviewing in Visual Studio Code
When you review a merge request in GitLab Workflow extension for VS Code, it provides a flat file list to navigate the changes. The flat file list lacks context, and can make it hard to understand where the changes are. In large codebases where files might have the same names across different directory paths, this can be even more problematic when reviewing.
With the release of v3.37.0, the GitLab Workflow extension now provides a toggle to switch between a flat list and a file tree view. This file tree view brings additional path information to help you navigate the changes, and get a complete picture of the merge request.
Thanks to Liming Jin for the amazing contribution!
GitLab Runner 14.5
We’re also releasing GitLab Runner 14.5 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.
Extract package metadata for npm packages
You can use the GitLab Package Registry to publish and share npm packages alongside your source code and pipelines. Prior to this release, however, GitLab did not extract all of the relevant metadata detailed in your package.json file. This is especially problematic when npm or Yarn relies on one of those fields. For example, the bin field defines executables to insert in $PATH. Without that field, your executables do not work.
As of this release, GitLab now extracts the abbreviated metadata for npm packages, including the bin field and others. If you publish packages that have one or more executable files to install into the $PATH, you can now rely on the GitLab Package Registry to work seamlessly. Please note that this change applies to new packages only. Any packages already published to the registry must be updated for the change to take effect. In addition, GitLab only extracts the abbreviated metadata, which excludes certain fields. GitLab-#344107 proposes extracting the full metadata set.
Order deployment by deployed time
Currently, the environment page sorts the list of deployments by the Created date, which is associated with the commit SHA change. To make it easier to view deployments over time, we have changed the default sorting order of this list to be by the finished_at field rather than the date of the commit. You can now see the running and most recently completed deployments at the top of the page and the rest of your deployments in descending order by the deployed time.
Restrict incident creation permissions to at least the Reporter role
You may have experienced a time where you created an incident when you actually meant to create an issue. Incidents are a specific issue-type, with a unique user interface and workflow that represent service disruptions or outages. In this release, only users with at least the Reporter role can create incidents. Restricting these permissions will help minimize the number of accidentally-created incidents.
New GitLab access token prefix and detection
With GitLab 14.5 we have updated the GitLab Personal Access Tokens and Project Access Tokens to include a standard prefix, glpat- by default for both GitLab.com and GitLab self-managed instances. We’ve also updated our Secret Detection scanning to detect this new pattern which will help protect you against accidentally leaked GitLab access tokens in commits.
This improvement helps make it easy to detect GitLab tokens leaked in commits and builds on community contribution improvements added in Gitlab 13.7 that allowed Admins to set Personal Access Token prefixes at the instance level, shoutout to @max-wittig and @dlouzan at Siemens for this contribution! Existing access tokens will not be modified but any new tokens will follow this new pattern or the custom pattern set by your self-managed GitLab instance.
If you would like to detect GitLab Personal Access Tokens and Project Access Tokens you can use the following regex detection pattern: glpat-[0-9a-zA-Z\-]{20}.
GitLab chart improvements
In GitLab 14.5, we now support the ability to set the Ingress API version via Helm values. This ability supports our work towards Kubernetes 1.22. When Kubernetes 1.22 is fully supported, when a user installs our Chart on a 1.22 cluster, a newer supported version on Ingress is be chosen. Users can manually specify the newer supported version if not installing against a live cluster, like when running a helm template.
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