gitlab-org/gitlab-ce v17.4.0

on GitLab

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.

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.

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.

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.

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:

• Project webhook requests
  
• Group webhook requests (Premium and Ultimate tier only)
  

You can now:

1. Get a list of project hook or group hook events.
   
2. Filter the list to see failures.
   
3. Use the 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!

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.

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.

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.

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.

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:

1. Find the file you want to show first. Right-click the name of the file to copy the link to it.
   
2. 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.

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.

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.

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.

What's new:

• GitLab Runner fleeting plugin for Azure compute (GA)
  

Bug Fixes:

• The entire step_script contents appear in the job log's after_script section when a Kubernetes executor job is cancelled before completion
  

The list of all changes is in the GitLab Runner CHANGELOG.

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.

Both pipeline and client-side Secret Detection now support detection of Anthropic API keys.

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.