Audit event recorded when Admin Mode enabled
GitLab now records an audit event when an administrator enables Admin Mode. This is helpful for security-related auditing, because Admin Mode allows the user to elevate permissions and change instance level settings.
Cancel import of a project from GitHub
When importing GitHub projects into GitLab, you could not cancel an import that was in progress.
You can now cancel imports from GitHub that are pending or in progress. If the import has already started, the imported files are kept.
Group owners can list user’s email addresses using the API
Group owners can now use the API to access the email addresses of any user provisioned by the group. A user is provisioned by the group when their account was created by SCIM, or by first sign in with SAML SSO for GitLab.com groups.
Previously, group owners could only access this information if a user’s email addresses were public.
Option for single sign-on users to stay signed in
Users signed in to GitLab with single sign-on were signed out frequently. Now, these users can select the Remember me checkbox and stay
signed in to GitLab for two weeks. When accessing group resources, users are redirected to their Identity Provider (IdP) once every 24 hours to verify the session. Depending on their IdP’s settings, users may have to re-authenticate to the IdP at this time.
Webhook push events support regular expressions
For webhooks triggered on push events, you can now define a regex pattern that aligns with your branching strategy. For example, you can use ^(feature|hotfix)/ to allow any push to the feature or hotfix branch to trigger an event.
Change the dimensions of images in Markdown
Before this release, there were no controls for changing the size
of images rendered within Markdown text areas. This often led to unwieldy images
with no control over how much space they took up in descriptions and comments.
You can now set the width and height of how images are rendered directly
in Markdown by appending the {width=x height=y} attributes to the image reference. Sizes can be specified with pixels or percentages.
Variables in merge request description templates
When creating a merge request, your organization may define merge request templates. These templates help make sure certain information is filled in, provide checklists for tasks, and more. However, they don’t contain any Git-level information that may be important for the merge request. This can make it challenging to provide commit message details, branch information, or even author information in a standardized and repeatable way.
Merge request description templates now support variables. Use these variables to build both business logic and important Git information, like commit and authoring info, into merge requests. Template variables ensure incoming merge requests always include the information your project requires, without tedious manual effort from contributors.
Thanks to David Barr for contributing this!
GitLab Runner 15.7
We’re also releasing GitLab Runner 15.7 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.
Limit the number of project or group CI/CD variables to 200
If your instance has project or group maintainers adding too many CI/CD variables, it could use a lot of resources to process all the variables for each pipeline. To ensure your pipelines continue to run efficiently, we have added a limit of 200 variables per group or project.
Projects and groups that already have over 200 CI/CD variables can continue to run pipelines as before, but will not be able to add any more variables. We recommend reducing the number of CI/CD variables down to less than 200 per group or project for optimal performance.
Add finished_after filter to Deployments API
With this update, you can filter the list of deployments in a project by finished_before or finished_after dates, to efficiently search for the relevant deployments in your workflow. Previously, filtering was allowed only by the updated dates.
Restrict access to a tunnel to specific environments
You can use the CI/CD tunnel provided by the GitLab agent for Kubernetes to integrate
your existing CI/CD workflows with your Kubernetes clusters. To save on resources and
simplify maintenance, you can share a tunnel with multiple groups and projects.
In previous releases, if a CI/CD tunnel was available for a project, you could use it
from all branches and in all environments. However, you could not restrict access to tunnels.
Now, you can restrict access to tunnels to certain environments, or to environments that match
a wildcard pattern.
Use the current project by default in GitOps configurations
When you install the agent, you typically create an agent without a configuration file. However, many features of the agent, including pull-based deployments, require a valid configuration.
In previous releases, pull-based deployments required you to specify the project where the manifest files are stored. If you had multiple projects, you needed a custom configuration file for each project. Now, you can omit the project ID and the agent will use the manifests in the current project. If your projects use the same conventions to store their manifests, you can use the same configuration file to set up an agent in every project.
On-demand DAST API GraphQL scans
As of GitLab 15.7, on-demand DAST API site profiles support configuring GraphQL APIs as the scan target. After selecting API as the site type, you can now select the GraphQL scan method and specify a GraphQL endpoint path. This ability has been available to DAST API scans in a CI/CD pipeline since we introduced the dast-api.gitlab-ci.yml template. With the switch from our legacy DAST API analyzer to our new analyzer for on-demand scans, we were able to add this functionality to our on-demand DAST API profiles.
See multiple findings in Code Quality changes view
We’ve improved GitLab Code Quality to make it easier to see and understand findings on merge requests when you’re reviewing changes.
The Changes view on merge requests now supports showing more than one finding on each line, and you can now expand the findings to view them without continuing to hover over them.
This change is now active on GitLab.com.
We plan to enable the feature flag by default for Self-Managed instances in GitLab 15.8.
Scan execution policy support for defining runner tags
Tags can now be defined in GitLab Scan Execution policies. This gives you the flexibility to specify which Runners will be used to execute your scan execution policy jobs.
Geo replicates dependency proxy
Geo now replicates the dependency proxy pull-through cache, which means that a populated cache of images is available at the newly promoted site after a failover. You can now be confident in performing regular failovers and avoid hitting Docker Hub rate limits, thus compromising the operational capabilities of the promoted site. This will help deliver a seamless failover experience to the end users.
Omnibus improvements
- GitLab 15.7 includes Mattermost 7.5, with message threads in calls, new Board templates, Board filtering by text properties, Board metrics, Channel user last activity, and more. This version also includes security updates and upgrade from earlier versions is recommended.
- GitLab 15.6 includes packages for openSUSE Leap 15.4.
Autocomplete suggestions for users in the global search bar
In the search bar, you can now see autocomplete suggestions for users. When you select a user, their profile page appears.
Automatic disabling of failing webhooks
To protect GitLab and users across the system from any potential abuse or misuse, we’ve implemented a feature to disable webhooks that fail consistently.
- Webhooks that return response codes in the
5xx range are understood to be failing intermittently and are temporarily disabled. These webhooks are initially disabled for 1 minute, which is extended on each retry up to a maximum of 24 hours.
- Webhooks that fail with
4xx errors are permanently disabled.
All project owners and maintainers are alerted in the app to investigate and re-enable any failed webhooks.
This feature is now available on GitLab.com and self-managed instances along with feature enhancements including handling cold starts.
Disable personal access tokens with application setting
You can now disable personal access tokens (PATs) at the instance level with a new application setting. Previously, there was no option to disable PATs.
Mask sensitive portions of webhook URLs
As you create webhooks to integrate with external services and receive GitLab data for event-driven workflows, you might have to supply callback URLs that include sensitive data. With this feature, you can now mask personal tokens, passwords, usernames, domains, and any other sensitive data when configuring your webhooks.
Users cannot set a known weak password
When a user sets their password, the password is now checked against a list of known weak passwords. If the password matches an entry on the list, the user must choose a
different one. This helps users choose more secure GitLab passwords.
Add spent time in the issue and merge request sidebar
Before 15.7, quick actions were the only way to add time spent on
an issue or merge request. While this method works, it’s not intuitive for all users.
To make recording time more efficient, you can now add time entries directly from the sidebar of an issue or a merge request.
Thanks for the contribution Marco Zille!
HTML comment support in the Content Editor
When you collaborate on a wiki page or blog post, you often come across inline HTML comments that are not meant to be rendered. Previously, the Content Editor would ignore these comments to reflect what the actual content would look like. The problem, however, was that making edits in the Content Editor could unexpectedly remove these comments from the file.
With this release, you can insert new HTML comments inline and edit comments already on the page. These comments appear in a way that indicates they won’t be rendered. This feature can help you manage longer wiki pages and is an important step towards editing issue descriptions and comments in future releases.
Add custom names to pipelines with workflow:name:
For some projects, the same pipeline can be configured to run differently for different variables or conditions, creating very distinct outcomes for successful pipelines. It can be hard for you to determine which version of that pipeline ran since there is no indication about the inputs used for that particular run. While labels like scheduled and API help, it is sometimes still difficult to identify specific pipelines.
Now you can set a pipeline name using the keyword workflow:name to better identify the pipeline with string, a CI/CD variable, or a combination of both.
Job execution status badge
The new job execution status badge in Admin Area > Runners and the {group_name} > CI/CD > Runners displays an at-a-glance indicator to determine if there are active jobs on a specific runner in the fleet. This iteration aims to simplify troubleshooting runner queue issues that impact time-to-result for CI builds.
Improved access control for the GitLab Package Registry
When you configure your project, you can choose the visibility level and enable/disable project features and their permissions. For example, you could restrict access to Project members only for the repository, issues, merge requests, and more. Although you can control several features like this, you can only turn the GitLab Package Registry on and off. You can’t set the Package Registry visibility to project members only or everyone with access. This issue has made it difficult for you to create a central registry with approved, vetted packages for distribution throughout your organization. As a workaround, you’ve had to add everyone to the project, which introduces security risks.
To help make you more efficient, we’ve added feature-specific controls for the Package Registry. Now project Administrators and Owners have more flexibility and control over how they share the Package Registry. By default, the Package Registry visibility is set to project members only. For more information about what permissions are required to view, download, or update packages, refer to the Package Registry visibility permissions documentation.
GraphQL API for environment and deployment permissions
We have exposed user permissions for environments and deployments through GraphQL. Now you can fetch user permissions for actions, such as update or destroy, for an environment or deployment via API.
Search for environments within folders
With this release, we improved support for searching for environments. Previously, you needed to type out the complete name of an environment if it was in a folder. Now, the search bar matches environments’ names, even if they are nested.
Dependency scanning support for npm lockfileVersion 3
GitLab Dependency Scanning now supports parsing and scanning dependencies stored in npm lockfiles where lockfileVersion: 3 is set.
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 was enabled in GitLab.com in GitLab 15.6.
The feature flag is now also enabled by default for Self-Managed instances in GitLab 15.7 and newer.
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.7 release milestone. These updates bring additional coverage, bug fixes, and improvements.
- Brakeman-based analyzer updated to version 5.3.1. See CHANGELOG for further details.
- CodeClimate-based analyzer updated to version 0.87.3. We’ve also disabled a network call that checked for available updates. See CHANGELOG for further details.
- Gitleaks-based analyzer updated to add a detection rule for systemd machine IDs and to exclude
go.mod and go.sum files from scanning. See CHANGELOG for further details.
- KICS-based analyzer updated to version 1.6.5. See CHANGELOG for further details. This version adds new rules, improves performance, and fixes a bug where some Terraform configurations could cause the analyzer to crash.
- Kubesec-based analyzer updated to fix a bug for manifests with multiple objects. See CHANGELOG for further details.
- NodeJSScan-based analyzer updated to version 0.3.4. See CHANGELOG for further details.
- Semgrep-based analyzer updated to improve performance of built-in Python rules and support automatic vulnerability resolution. See CHANGELOG for further details.
- Multiple analyzers updated to include
git so that the analyzer can remove vulnerabilities in files that aren’t committed to the repository.
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.
Set default compliance framework for new projects in a group
In previous versions of GitLab, you could create a compliance framework for a group but needed to apply it to each new project individually.
Now you can set a compliance framework as the default framework to apply to new projects created in a group. Existing projects don’t have the
default framework automatically applied.
GitLab chart improvements
- Cloud Native GitLab replaces
alpine-certificates behaviors with gitlab-base in an upcoming release. 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, is that we will be changing the image name and tags used. We will maintain a mirrored tag for a short period.
Specify custom NTP server when running Geo health check
For Geo to function correctly, the clocks between Geo sites must be synchronized. When running Geo health checks, you can now specify a custom NTP server to override pool.ntp.org. This change lets you validate your clocks if you are using your own time server, or if you set up Geo in an offline environment and it can’t reach the default NTP server.
Improved design for filtering global search results
Previously, global search scopes appeared as tabs below the search bar. This design wasn’t very intuitive and limited the number of available filtering options.
With this release, global search scopes now appear on the left sidebar. The new design makes it easier to filter results and allows for additional filtering options depending on content types. With this improvement, every page in global search results has a left sidebar and a consistent layout.
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