GitLab 15.4 released with Suggested Reviewers and better VS Code CI/CD experience
GitLab 15.4 released with Suggested Reviewers open beta, improved CI/CD integration in VS Code, streamlined account verification, Pages Pipeline Wizard and much more!
These are just a few highlights from the 60+ improvements in this release. Read on to check out all of the great updates below.
We thank the wider GitLab community for the 186 contributions they provided to GitLab 15.4! At 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 15.5 release kickoff video.
Deciding the right person to review your merge request isn’t always straightforward or obvious. Choosing the wrong reviewer can cause delays, low quality reviews, back and forth reassigning reviewers, or even no review at all.
Now, GitLab can recommend a reviewer with Suggested Reviewers. Using the changes in a merge request and a project’s contribution graph, machine learning powered suggestions appear in the reviewer dropdown in the merge request sidebar.
This feature is currently in beta behind a feature flag. It will be rolling out to all Ultimate GitLab.com customers over the next week.
You can use GitLab Pages to define custom domains for your website. Too many custom domains, however, can result in slow response times from the Pages API and impact the overall reliability of the service. Now you can limit the maximum number of custom domains per project at the instance level and strike the right balance for your needs. The default value is 0 (unlimited).
We’ve made it much easier to get started with GitLab Pages. Instead of
creating configuration files by hand, build them interactively using the
GitLab UI. Just answer a few basic questions on how your app is built,
and we’ll build the .gitlab-ci.yml file to get you started.
This is the first time we’re using our new Pipeline Wizard,
a tool that makes it easy to create .gitlab-ci.yml files by building
them in the GitLab UI. You can look forward to more simplified
onboarding helpers like this one.
When you’re constructing complicated GitLab CI configurations that may contain include: or extends: keywords, it’s challenging to ensure the configuration is valid and the resulting file has your expected configuration. Use GitLab Workflow for Visual Studio Code to preview your merged GitLab CI/CD configuration file directly in VS Code. You can view your changes locally, and ensure your configuration is as you expect, before you commit and push.
GitLab Workflow v3.50.0 also provides more CI/CD pipeline interactions to help you avoid context-switching:
Working with tables in Markdown can be a bit cumbersome. Not only is it difficult to figure out the correct number of pipes and empty cells, but the table output is static when you save your document. If you have to sort the table by the third column in an ascending order, you end up rewriting the whole thing.
Now you can insert data-driven tables using JSON syntax as follows:
Write or export a table in JSON.
Wrap JSON in a code block that starts with triple backticks followed by json:table.
Save your issue, submit your comment, or publish your page.
In the rendered table, you can also enable:
Sorting for specific fields using "sortable": true
Dynamic filtering of data using "filter" : true
Now it’s as simple as a click when you have to re-sort that 100-row table and as easy as a web search when you have to find that one issue reference lost in a sea of nearly identical URLs.
New GitLab users created using SAML or SCIM that belong to a
verified domain
no longer receive the GitLab account verification e-mail.
This reduces account activation friction. Accounts generated through a provisioning process are already verified,
so users should not have to individually verify them manually.
Collaboration and efficiency are key when working quickly through an incident.
Users don’t want to spend valuable time setting up collaboration tools for each incident.
With this release, you can more easily surface the incident Slack channel, Zoom meeting space, or links to any relevant resource for resolving incidents.
When you run jobs on GitLab SaaS Linux runners, you now have access to more powerful machine types: medium and large. With these two machine types, you have more choices for your GitLab SaaS CI/CD jobs. And with 100% job isolation on an ephemeral virtual machine, and security and autoscaling fully managed by GitLab, you can confidently run your critical CI/CD jobs on GitLab SaaS.
To protect GitLab and users across the system from the potential abuse or misuse of a small few, 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 10 minutes, 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 and can investigate and re-enable any failed webhooks.
Administrators can now merge source topics into target topics. This action deletes the source topic and moves all assigned projects to the target topic. This way, you can eliminate duplicate topics that might only differ in spelling, and keep your projects organized. Thanks to Jonas Wälter for this community contribution.
The App Home provides a central location for GitLab to communicate new Slack features and familiarize you with existing ones. As Slack is one of our most heavily used integrations, we’re working to simplify and consolidate functionality such as slash commands and notifications for the GitLab Slack application. The App Home gives us a way to engage directly with you throughout the process!
To ensure your GitLab Slack application is up to date:
You can now use the status settings in your profile page to schedule when to automatically clear your status. Previously, you could do this only from the Set status modal.
You can now specify a value to use as the verification token
that streaming audit events use.
This is a great improvement for situations where the value you have to use for validating events is dictated by a third-party system. For example,
if you are sending streaming audit events to a third-party system, and that system requires a specific value, you can now specify the value in GitLab
directly rather than having to see what value GitLab randomly generates and then updating the other system afterwards.
For the Google Chat integration, notifications related to a single issue or merge request are now organized into threads. This contribution from Chetan Sarva reduces the noise and searching required to understand ongoing discussions.
New to the Google Chat integration? Get started with our documentation.
Tasks represent discrete work units necessary to complete an issue.
You can now assign tasks to a single individual in GitLab Free or multiple people
in GitLab Premium or Ultimate. Assigned tasks can be accessed from your personal
issues dashboard and are filterable by assignee from within a project’s issue
list.
When you type a comment on a design, it’s now auto-saved, preventing you from losing progress if you accidentally navigate away before submitting the comment.
In 15.0, we announced the deprecation of manual iteration management. We received a significant amount of feedback that in certain cases, automated iteration cadence management was not flexible enough.
In 15.4, we’re re-introducing the ability to manually create iterations and providing improved controls for managing the automation settings within a cadence. You can now disable or re-enable automatic scheduling or change the duration and upcoming iterations at any point in time.
Merge requests and approvals are two of the most used and helpful features in GitLab. Still, in previous versions, you may have had trouble finding the project settings for these features. It wasn’t intuitive or clear that they were in Settings > General.
Now you can more easily find the project settings for merge requests and approvals by navigating directly to Settings > Merge requests.
We’re also releasing GitLab Runner 15.4 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.
In this update, we have added a new endpoint for the protected environments API that lets you update the configuration settings. You can use the endpoint for changing who is allowed to deploy and how many approvals are required.
The Terraform CI/CD templates provide you with a quick and easy way to integrate your projects with Terraform. However, changes to the gl-terraform wrapper script could introduce breaking changes to even the stable Terraform template. In this release, changes to the wrapper script dramatically reduce the likelihood of breaking changes outside of major releases.
You can now see and track the comments and approvals left by users when reviewing a deployment, providing more context as to why a manual job was approved or rejected. This functionality is also useful for organisations in highly regulated industries that need to audit release events.
Every second counts when users are working to resolve an incident. In this release, you can use a quick action to add one or more events to the incident timeline.
GitLab Static Application Security Testing (SAST) now offers Semgrep-based scanning for C# code.
As with the other languages we have transitioned to Semgrep-based scanning, C# scanning coverage uses GitLab-managed detection rules to detect a variety of security issues.
The new Semgrep-based scanning runs significantly faster than the existing analyzer based on Security Code Scan.
It also doesn’t need to compile your code before scanning, so it’s simpler to use.
GitLab’s Static Analysis and Vulnerability Research teams worked together to translate rules to the Semgrep format, preserving most existing rules.
We also updated, refined, and tested the rules as we converted them.
If you use the GitLab-managed SAST template (SAST.gitlab-ci.yml), both Semgrep- and Security Code Scan-based analyzers now run whenever C# code is found.
In GitLab Ultimate, the Security Dashboard combines findings from the two analyzers, so you won’t see duplicate vulnerability reports.
In a future release, we’ll change the GitLab-managed SAST template (SAST.gitlab-ci.yml) to only run the Semgrep-based analyzer for C# code.
The Security Code Scan-based analyzer will still scan code for other .NET languages.
If you have any questions, feedback, or issues with the new Semgrep-based C# scanning, please file an issue, we’ll be glad to help.
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.4 release milestone. These updates bring additional coverage, bug fixes, and improvements.
Kics analyzer updated to add additional rules, fix bugs, and update to kics version 1.5.13. See CHANGELOG for details.
NodeJSScan analyzer updated to version 0.3.3. See CHANGELOG for details.
Security Code Scan analyzer updated to version 5.6.5. See CHANGELOG for details.
Semgrep analyzer updated to version 0.110.0. See CHANGELOG for details.
You can now set the Semgrep --max-memory flag by using the new SAST_SCANNER_ALLOWED_CLI_OPTS CI/CD variable. This variable accepts a limited set of options and passes them through to the underlying scanner.
Secrets analyzer updated. See CHANGELOG for details.
We’ve fixed a bug that caused a historic scan to be run if the SECRET_DETECTION_HISTORIC_SCAN CI/CD variable was set at all, regardless of the variable’s value.
SpotBugs analyzer updated to use ‘assemble’ task for Gradle projects. See CHANGELOG for details. We thank community contributor @sbrochet for making this improvement.
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.
You can now use the API to immediately delete individual subgroups. Prior to this release, you could only delete individual subgroups from group settings in the UI.
Pre-defined push rules in the left sidebar for groups have been moved and will now appear under Settings > Repository, which mirrors the location of push rules in projects. Group maintainers will still have access to this page.
Previously, IP address restrictions could only be configured in the GitLab UI. Now, you can add a comma separated-list of IP addresses or subnet masks using the API. This allows you to configure IP address restrictions programatically.
Shimo is a popular cloud-productivity suite that includes documentation, spreadsheets, slideshows, and whiteboards. With this integration, you can use the Shimo Wiki directly within GitLab.
The current top bar navigation can be confusing and overwhelming with the number of options that are presented. With this release, we have worked to improve the usability and understanding of this area.
There are 3 ways we focused on improving the usability. First, we reduced confusion around the menu options by arranging them in logical groupings. Second, we removed unnecessary noise by eliminating duplicative navigation items as well as removed the label “Menu” from the button. Finally, to make global search more accessible, we have shifted search to be next to the menu icon. This aligns with our goal of tying search to navigation and helping users get back to the things they are working on.
You can now see issue health status in boards. Each issue card will show the health status, allowing teams to get an overview at a glance of the health of their team’s work.
Project maintainers and owners can now delete attachments in a project through our GraphQL API. This functionality is essential in cases when sensitive data is accidentally uploaded in an image or for managing disk usage for a GitLab instance.
When your board lists have dozens of cards in them, it’s sometimes hard to manually drag an issue from the top to the bottom or bottom to the top. Cards on issue and epic boards now have an action menu with options to move the card to the top or bottom of the card’s current list.
The list of runners now uses GitLab’s updated list design standards. If you are a self-managed GitLab administrator, or group owner, critical runner fleet data is now visible. In addition, the new interface elements should help reduce your cognitive load and make the page easier to scan. Instead of text, icons communicate the status, and tags have their own column.
In this update, you can now see the associated release when viewing a specific tag’s information page. This allows you to easily know if a release has been created based on that specific tag and to navigate to the release.
You can now use the agent for Kubernetes to deploy
Helm charts to your Kubernetes cluster.
Until now, the agent for Kubernetes only supported vanilla Kubernetes manifest files in its GitOps
workflow. To benefit from the GitOps workflow, Helm users had to use a CI/CD job to render and commit
resources.
The current release ships with Alpha
support for Helm. Because Helm is a mature product, we consider the
solution performant. However, known issues exist
and the API might change without prior notice. We welcome your feedback in the
related epic, where we discuss
future improvements and next steps.
With this update, on the Environments page, you can now easily see tags that are related to deployments and specifically, the deployed commit. This lets you more easily determine what code is currently or has been previously deployed to an environment.
With this update, you can now use a variable when specifying the lifetime of an environment. This allows you to have more flexibility and dynamic behavior for managing temporary environments and when they should be stopped.
Incident timelines are an important part of record keeping for incidents. Incident timelines break down what happens during an incident, and the steps taken for the incident to be resolved.
Sometimes comments from the incident are an important event in the timeline of the incident. Instead of manually copying the important comments, you can now select a button to add the comment to the incident timeline.
As of GitLab 15.4, DAST API and API Fuzzing support GraphQL schemas for defining what is covered by the test. In previous versions of GitLab, DAST API and API Fuzzing supported testing GraphQL APIs, but the test required a Postman collection or a HAR file to define the test parameters. By supporting the GraphQL schema that is already a part of your API, we can now easily test GraphQL APIs without the need of a separate definition. Depending on which type of test you are configuring, set the DAST_API_GRAPHQL or FUZZAPI_GRAPHQL environment variable to point to the GraphQL endpoint. For applications with introspection enabled, this configures the test to run with the schema as the definition of the test parameters. For applications with introspection disabled, you will also need to set the DAST_API_GRAPHQL_SCHEMA variable to point the test to a schema file.
Semgrep-based scanning coverage for each of these languages uses GitLab-managed detection rules to detect a variety of security issues.
GitLab’s Static Analysis and Vulnerability Research teams worked together to translate rules from the previous analyzers to the Semgrep format, preserving most existing rules.
This change is part of our long-term strategy to deliver a more consistent user experience, faster scan times, and reduced CI minute usage.
GitLab 15.4 includes Mattermost 7.2, with message forwarding for channels and much more. This version also includes security updates, so upgrading from older versions is recommended.
Bug fixes, performance improvements, and UI improvements
At GitLab, we’re dedicated to providing the best possible experience for our users. With every release, we work tirelessly to fix bugs, improve performance, and enhance UI. Whether you’re one of the over 1 million users on GitLab.com or using our platform elsewhere, we’re committed to making sure your time with us is smooth and seamless.
Click the links below to see all the bug fixes, performance enhancements, and UI improvements we’ve delivered in 15.4.
Certificate-based Kubernetes integration available on GitLab.com until Feb 2023
If you began using the certificate-based Kubernetes integration on GitLab.com before GitLab 15.0, you could continue using it until 15.6. Now, support will be removed in 15.8 instead. This change means you have until February 2023 to move to the agent for Kubernetes.
Certificate-based Kubernetes integration available on self-managed GitLab until 17.0
When the certificate-based Kubernetes integration was deprecated, you were expected to migrate to an alternative solution before its removal in GitLab 16.0. Now, support will be removed in 17.0. This change means you have until May 2024 to move to the agent for Kubernetes. During this time, GitLab plans to ship a set of updated features for the agent.
In GitLab 15.4, we updated Geo file synchronization concurrency limits. Prior to GitLab 15.4, the number of file replication jobs was unintentionally limited to half of the File synchronization concurrency limit value. All blob types are now handled by the self-service framework, so Geo now uses the correct File synchronization concurrency limit set in the tuning settings.
The updated logic can increase the load on primary and secondary sites, potentially leading to slower response times. You should review your concurrency limits aftr uprading to 15.4 and tune them as necessary.
GitLab-managed object storage replication is disabled, and LFS objects are created while importing a project with object storage enabled.
GitLab-managed replication to sync object storage is enabled and subsequently disabled.
A fix is included in 15.3.3. Customers who have both LFS enabled and LFS objects being replicated across Geo sites should upgrade directly to 15.3.3 to reduce the risk of data loss on secondary sites.
GitLab 15.4.1 was affected by a licensing cache issue which meant some premium features of GitLab will stop working if you add a new license.
Workarounds for this issue include:
- Restarting all Rails, Sidekiq, and Gitaly nodes after applying a new license. This clears the relevant license caches and allows all premium features to operate correctly.
- Upgrading to a version that is not impacted by this issue, for example 15.4.2.
A fix is included in GitLab 15.3.3. Customers with the following configuration should upgrade to GitLab 15.3.3 or later:
LFS is enabled.
LFS objects are being replicated across Geo sites.
Repositories are being pulled by using a Geo secondary site.
In GitLab 15.5 we will introduce the use of GitLab Logger by default for the GitLab Helm Chart. For users who have custom log parsers in place, be aware that this will automatically wrap all logs in structured JSON where they were plaintext prior.
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