On September 19, 2024, GitLab 17.4 was released with the following features.
In addition, we want to thank all of our contributors, including this month's notable contributor.
Everyone can nominate GitLab’s community contributors! Show your support for our active candidates or add a new nomination! 🙌
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!
Elevate your coding workflow and receive more context-aware Code Suggestions using the contents of other open tabs.
This improvement to Code Suggestions now uses the content of your open editor tabs to provide more relevant and accurate code recommendations.
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.
You can now configure sudo access for your workspace, making it easier than ever to install, configure, and run dependencies directly in your development environment. We’ve implemented three secure methods to ensure a seamless development experience:
With this feature, you can fully customize your environment to match your workflow and project needs.
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.
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:
To learn more, see the announcement blog.
GitLab 17.4 includes PostgreSQL 16 by default for fresh installations of GitLab.
GitLab 17.7 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.
allowed_email_domains_list attribute in the Groups API.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.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.
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:
You can now:
id of any event to resend it.Thanks to Phawin for this community contribution!
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.
Thanks to Van for this community contribution!
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:
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.
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:
Feedback about linked files can be left in issue 439582.
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:
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.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.
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.
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 behaviorsuffix: never enforces all jobs names are unique and will fail pipelines if collisions occur, which has been the default behavior since 17.2With 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 15.3 added support for ingesting CycloneDX SBOMs.
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.
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.
The migration only resolves vulnerabilities that you haven’t confirmed or dismissed, and it doesn’t affect vulnerabilities that were automatically translated to Semgrep-based scanning.
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.
The list of all changes is in the GitLab Runner CHANGELOG.