GitLab 17.4 released with improved context in GitLab Duo
GitLab 17.4 released with more context-aware GitLab Duo Code Suggestions using open tabs, auto-merge when all checks pass, extension marketplace in the Web IDE, list Kubernetes resource events and much more!
These are just a few highlights from the 140+ improvements in this release. Read on to check out all of the great updates below.
To the wider GitLab community, thank you for the 220+ contributions you provided to GitLab 17.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 17.5 release kickoff video.
Archish Thakkar is one of GitLab’s top contributors this year with 46 closed issues and 119 merged MRs. These contributions have helped Archish earn top spots in the last two GitLab Hackathons. He is a Senior Software Engineer at Middleware and passionate open source contributor.
Archish was nominated by Peter Leitzen, Staff Backend Engineer, Engineering Productivity at GitLab. The nomination was supported by Max Woolf, Staff Backend Engineer at GitLab, and James Nutt, Senior Backend Engineer at GitLab. Archish’s contributions have increased in the past two months where he has consistently demonstrated outstanding commitment to improving GitLab’s codebase, contributing multiple QoL (Quality of Life) fixes and reducing technical debt.
Many thanks to Archish and the rest of GitLab’s open source contributors for co-creating GitLab!
Merge requests have many required checks that must pass before they are mergeable. These checks can include approvals, unresolved threads, pipelines, and other items that need to be satisfied. When you’re responsible for merging code, it can be hard to keep track of all of these events, and know when to come back and check to see if a merge request can be merged.
GitLab now supports Auto-merge for all checks in merge requests. Auto-merge enables any user who is eligible to merge to set a merge request to Auto-merge, even before all the required checks have passed. As the merge request continues through its lifecycle, the merge request automagically merges after the last failing check passes.
We’re really excited about this improvement to accelerate your merge request workflows. You can leave feedback about this feature in issue 438395.
We’re thrilled to announce the launch of the extension marketplace in the Web IDE on GitLab.com. With the extension marketplace, you can discover, install, and manage third-party extensions and enhance your development experience. Some extensions are not compatible with the web-only version because they require a local runtime environment. However, you can still choose from thousands of extensions to boost your productivity or customize your workflow.
The extension marketplace is disabled by default. To get started, you can enable the extension marketplace in the Integrations section of your user preferences. For enterprise users, only users with the Owner role for a top-level group can enable the extension marketplace.
GitLab provides a real-time view into your pods and streaming pod logs. Until now, however, we didn’t show you resource-specific event information from the UI,
so you still had to use 3rd party tools to debug Kubernetes deployments.
This release adds events to the resource details view of the dashboard for Kubernetes.
This is the first time we’ve added events to the UI. Currently, events are refreshed every time you open the resource details view. You can track the development of real-time event streaming in issue 470042.
Previously, to create a GitLab Pages project, you needed a domain formatted like name.example.io
or name.pages.example.io. This requirement meant you had to set up wildcard DNS records and
TLS certificate. In this release, setting up a GitLab Pages project without a DNS wildcard has
moved from beta to generally available.
Removing the requirement for wildcard certificates eases administrative overhead associated with
GitLab Pages. Some customers can’t use GitLab Pages because of organizational restrictions on
wildcard DNS records or certificates.
This release introduces Pages parallel deployments in beta. You can now easily preview changes and manage parallel deployments for your
GitLab Pages sites. This enhancement allows for seamless experimentation with new ideas, so you can test and refine your sites with confidence. By
catching any issues early, you can ensure that the live site remains stable and polished, building on the already great foundation of GitLab Pages.
Additionally, parallel deployments can be useful for localization when you deploy different language versions of an application or website.
Getting up to speed on lengthy issue discussions can be a significant time investment. With this release, AI-generated issue discussion summarization has been integrated with Duo Chat and is now generally available for GitLab.com, Self-managed, and Dedicated customers.
We’re excited to announce that our Advanced Static Application Security Testing (SAST) scanner is now generally available for all GitLab Ultimate customers.
Advanced SAST is a new scanner powered by the technology we acquired from Oxeye earlier this year. It uses a proprietary detection engine with rules informed by in-house security research to identify exploitable vulnerabilities in first-party code. It delivers more accurate results so developers and security teams don’t have to sort through the noise of false-positive results.
Along with the new scanning engine, GitLab 17.4 includes:
A new code-flow view that traces a vulnerability’s path across files and functions.
An automatic migration that allows Advanced SAST to “take over” existing results from previous GitLab SAST scanners.
You might not want anyone to see the value of a variable after it is saved to project settings. You can now select the new Masked and hidden visibility option when creating a CI/CD variable. Selecting this option will permanently mask the value of the variable in the CI/CD settings UI, restricting the value from being displayed to anyone in the future and decreasing visibility of your data.
From this release, we support an idempotency key in the headers of webhook requests. An idempotency key is a unique ID that remains consistent across webhook retries, which
allows webhook clients to detect retries. Use the Idempotency-Key header to ensure the idempotency of webhook effects on integrations.
You can now adjust the wiki sidebar to see longer page titles, improving the overall discoverability of
content. As wiki content grows, having a resizable sidebar helps manage and browse through complex hierarchies or extensive
lists of pages more efficiently.
Code intelligence in GitLab provides code navigation features when browsing a repository. Getting started with code navigation is often complicated, as you must configure a CI/CD job. This job can require custom scripting to provide the correct output and artifacts.
GitLab now supports an official Code intelligence CI/CD component for easier setup. Add this component to your project by following the instructions for using a component. This greatly simplifies adopting code intelligence in GitLab.
Currently, the component supports these languages:
Go version 1.21 or later.
TypeScript or JavaScript.
We’ll continue to evaluate available SCIP indexers as we look to broaden language support for the new component. If you’re interested in adding support for a language, please open a merge request in the code intelligence component project.
We’re also releasing GitLab Runner 17.4 today! GitLab Runner is the highly-scalable build 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.
Due to an implementation issue, the action: prepare, action: verify, and action: access jobs
become manual jobs when they run against a protected environment. These jobs require manual interaction to run,
although they don’t require any additional approvals.
Issue 390025 proposes to fix the implementation, so these jobs won’t be turned into manual jobs.
After this proposed change, to keep the current behavior, you will need to
explicitly set the jobs to manual.
For now, you can change to the new implementation now by enabling the prevent_blocking_non_deployment_jobs feature flag.
Any proposed breaking changes are intended to differentiate the behavior of the
environment.action: prepare | verify | access values.
The environment.action: access keyword will remain the closest to its current behavior.
To prevent future compatibility issues, you should review your use of these keywords now.
You can learn more about these proposed changes in the following issues:
In GitLab 17.0, 16.0, and 15.4, we streamlined GitLab SAST so it uses fewer separate analyzers to scan your code for vulnerabilities.
Now, after you upgrade to GitLab 17.3.1 or later, a one-time data migration will automatically resolve leftover vulnerabilities from the analyzers that have reached End of Support.
This helps clean up your Vulnerability Report so you can focus on the vulnerabilities that are still detected by the most up-to-date analyzers.
In GitLab 17.4 we have added support for ingesting CycloneDX version 1.6 SBOMs.
Fields relating to hardware (HBOM), services (SaaSBOM), and AI/ML models (AI/ML-BOM) are not currently supported. SBOMs that contain data relating to these BOMs will be processed, but the data will not be analyzed or presented to users. Support for these other BOM-types is being tracked in this epic.
Administrators can now decide if they want to enforce a mandatory expiration date for personal, project, and group access tokens. If administrators disable this setting, any new access token generated will not be required to have an expiration date. By default this setting is enabled, and an expiration less than that of the maximum allowed lifetime is required. This setting is available in GitLab 16.11 and later.
An enhancement to the 17.2 release of pipeline execution policies, policy creators may now configure pipeline execution policies to handle collisions in job names gracefully. With the policy.yml for the pipeline execution policy, you may now configure the following options:
suffix: on_conflict configures the policy to gracefully handle collisions by renaming policy jobs, which is the new default behavior
suffix: never enforces all jobs names are unique and will fail pipelines if collisions occur, which has been the default behavior since 17.2
With this improvement, you can ensure security and compliance jobs executed within a pipeline execution policy always run, while also preventing unnecessary impacts to developers downstream.
In a follow-up enhancement, we will introduce the configuration option within the policy editor.
GitLab 17.4 includes PostgreSQL 16 by default for fresh installations of GitLab.
GitLab 17.5 will include OpenSSL V3. This will affect Omnibus instances with external integration setup’s that do not meet the minimum requirements of TLS 1.2 or above for outbound connections, along with at least 112-bit encryption for TLS certificates. Please review our OpenSSL upgrade documentation for more information or if your are unsure if your instance will be affected.
Previously, you could only add domain restrictions at the group level in the UI. Now, you can also do this by using the new allowed_email_domains_list attribute in the Groups API.
Previously, GitLab provided the ability to resend webhook requests only in the UI, which was inefficient if many
requests failed.
So that you can handle failed webhook requests programmatically, in this release thanks to a community contribution, we
added API endpoints for resending them:
Our GitLab Duo plugin for JetBrains now offers a more secure and streamlined onboarding process. Sign in quickly and securely with OAuth. It integrates seamlessly with your existing workflow, with no personal access token required!
When you share a link to a specific file in a merge request, it’s often because you want the person to look at something within that file. Merge requests previously needed to load all of the files before scrolling to the specific position you’ve referenced. Linking directly to a file is a great way to improve the speed of collaboration in merge requests:
Find the file you want to show first. Right-click the name of the file to copy the link to it.
When you visit that link, your chosen file is shown at the top of the list. The file browser shows a link icon next to the file name.
Feedback about linked files can be left in issue 439582.
You can now use JaCoCo coverage reports, a popular standard for coverage calculation, inside your merge requests. The feature is available as beta, but ready for testing by anyone who wants to use JaCoCo coverage reports right away. If you have any feedback, feel free to contribute to the feedback issue.
Although you can configure Flux to trigger reconciliations at specified intervals, there are situations where you might want an immediate reconciliation. In past releases, you could trigger the reconciliation from a CI/CD pipeline or from the command line. In GitLab 17.4, you can now trigger a reconciliation from a dashboard for Kubernetes with no additional configuration.
To trigger a reconciliation, go to a configured dashboard and select the Flux status badge.
In GitLab 17.4, we added a setting to security policies you can use to grant read access to pipeline-execution.yml files for all linked projects. This setting gives you more flexibility to enable users, bots, or tokens that enforce pipeline execution globally across projects. For example, you can ensure a group or project access tokens can read security policy configurations in order to trigger pipelines during pipeline execution. You still can’t view the security policy project repository or YAML directly. The configuration is used only during pipeline creation.
To configure the setting, go to the security policy project you want to share. Select Settings > General > Visibility, project features, permissions, scroll to Pipeline execution policies, and enable the Grant access to this repository for projects linked to it as the security policy project source for security policies toggle.
In GitLab 17.3, we provided users with the ability to add multiple compliance frameworks to a project.
Now you can search by multiple compliance frameworks, which makes it easier to search for projects that have multiple compliance frameworks attached to them.
We have simplified the display of the source column on the Members page for groups and projects. Direct members are still indicated as Direct member. Inherited members are now listed as Inherited from followed by the group name. Members that were added by inviting a group to the group or project are listed as Invited group followed by the group name. For members that inherited from an invited group that was added to a parent group, we now display the last step to keep the display actionable for users managing membership.
We added new endpoints to the Groups API and Projects API to retrieve the groups that have been invited to a group or project. This functionality is available only on the Members page of a group or project. We hope that this addition will make it easier to automate membership management for your groups and projects. The endpoints are rate-limited to 60 requests per minute per user.
Users on self-managed instances will now receive an email when they are assigned a GitLab Duo seat. Previously, you wouldn’t know you were assigned a seat unless someone told you, or you noticed new functionality in the GitLab UI.
To disable this email, an administrator can disable the duo_seat_assignment_email_for_sm feature flag.
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 17.4.
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