gitlab-org/gitlab-foss v17.3.0

on GitLab

GitLab 17.3 includes packages for supporting Raspberry Pi OS 12.

Debian 10 has reached EOL on June 30th, 2024. GitLab will remove support for Debian 10 in GitLab 17.6.

We have updated the sorting and filtering functionality of the project and group overview in Your Work. Previously, in the Your Work page for projects, you could filter by name and language, and use a pre-defined set of sorting options. We have standardized the sorting options to include Name, Created date, Updated date, and Stars. We also added a navigation element to sort in ascending or descending order, and moved the language filter to the filter menu. Now you can find archived projects in the new Inactive tab. Additionally, we added a Role filter that allows you to search for projects you are the Owner of.

In the Your Work page for groups, we have standardized the sorting options to include Name, Created date, and Updated date, and added a navigation element to sort in ascending or descending order.

We welcome feedback about these changes in #438322.

This release adds full support for Kubernetes version 1.30, released in April 2024. If you deploy your apps to Kubernetes, you can now upgrade your connected clusters to the most recent version and take advantage of all its features.

You can read more about our Kubernetes support policy and other supported Kubernetes versions.

Until now, you could only control whether a project inherited integration settings, or used its own settings, using the UI.

In this milestone, we are introducing a new use_inherited_settings parameter to the REST API of all integrations. This parameter allows you to use the API to set whether or not a project inherits integration settings. If not set, the default behavior is false (use the project's own settings).

In 17.2, we added the ability to search for project settings by using the command palette. This change made it easier to quickly find the settings you need.

With 17.3, you can now search for group settings from the command palette as well. Try it out by visiting a group, selecting Search or go to, entering command mode with >, and typing the name of a settings section, like Merge request approvals. Select a result to jump right to the setting itself.

Have you ever needed to restart or delete a failing pod in Kubernetes? Until now, you had to leave GitLab, use another tool to connect to the cluster, stop the pod, and wait for a new pod to start. GitLab now has built-in support for deleting pods, so you can smoothly troubleshoot your Kubernetes clusters.

You can stop a pod from a dashboard for Kubernetes, which lists all the pods across your cluster or namespace.

Do you want to connect to a Kubernetes cluster from your local terminal or using one of the desktop Kubernetes GUI tools? GitLab allows you to connect to a terminal using the user access feature of the agent for Kubernetes. Previously, finding commands required navigating out of GitLab to browse the documentation. Now, GitLab provides the connect command from the UI. GitLab can even help you configure user access!

To retrieve the connection command, either go to a Kubernetes dashboard, or to the agent list.

Tasks are frequently used to break down issues into engineering implementation steps. Before this release, there was no way to connect a merge request to a task it implements. You can now use the same closing pattern that you would when referencing issues from a merge request description to connect a merge request to a task. From the task view, connected merge requests are visible from the sidebar. If your project has the auto-close setting enabled, the task will automatically close when the connected merge request is merged into your default branch.

You can now effortlessly update parent assignments for OKRs and tasks, directly from the child record, eliminating the need to navigate back and forth. This is a great step towards our goal of improving efficiency with your workflows.

You can now easily report abuse for work items directly from the Actions menu, just like you can with legacy issues. This new feature helps keep your workspace clean and safe by allowing you to quickly flag inappropriate content, ensuring a better collaborative environment for your team.

You can now resolve threads in tasks, objectives, and key results, making it easier to manage and track important conversations. Resolved threads are collapsed by default, helping you focus on active discussions and streamline your collaboration workflows.

For tighter security in sensitive environments, you can now configure custom HTTP agent options, including client certificates and certificate authorities, directly in your JetBrains IDE settings.

Currently, the process for removing content from a repository is complicated, and you might have to force push the project to GitLab. This is prone to errors and can cause you to temporarily turn off protections to enable the push. It can be even harder to delete files that use too much space within the repository.

You can now use the new repository maintenance option in project settings to remove blobs based on a list of object IDs. With this new method, you can selectively remove content without the need to force push a project back to GitLab.

In the event that secrets or other content has been pushed that needs to be redacted from a project, we're also introducing a new option to redact text. Provide a string that GitLab will replace with ***REMOVED*** in files across the project. After the text has been redacted, run housekeeping to remove old versions of the string.

This new UI streamlines the way you can manage your repositories when content needs to be removed.

You can now quickly find a specific job by searching for a job name.

Previously, you could only filter the list of jobs by status, requiring manual scrolling to find a specific job. With this release, you can now enter a job name to filter the results. The results will only include jobs in pipelines that ran after the release of GitLab 17.3.

We're releasing GitLab Runner 17.3 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.

Bug fixes:

• Jobs appear to hang when canceled in the Kubernetes runner
• Log level not updated when not specified
• Job log adds extra newlines when using the runner Kubernetes executor

For a list of all changes, see the GitLab Runner changelog.

The details page for a CI/CD component in the catalog provides useful information about the component. In this release we've added two more columns to the table that shows information about available inputs. The new Description and Type columns make it much easier to understand what an input is used for, and what type of value is expected.

Administrators can now disable or re-enable instance personal access tokens through the Admin UI. Previously, administrators had to use the application settings API or the GitLab Rails console to do this.

You can now add your Bluesky did:plc identifier to your GitLab profile.

Thank you Dominique for your contribution!

GitLab's sign out process has been improved so that cookies from sibling subdomains are not deleted on sign out. Previously, these cookies were deleted, causing users to be signed out of other subdomain services on the same top-level domain as GitLab. For example, if a user has Kibana set up on kibana.example.com and GitLab set up on gitlab.example.com, signing out from GitLab will no longer sign the user out from Kibana.

Thank you Guilherme C. Souza for your contribution!