gitlab-org/gitlab-foss v17.2.0

on GitLab

We have updated the sorting and filtering functionality of the group overview page. The search element now stretches across the whole page, allowing you to see your search strings better. We have standardized the sorting options to Name, Created date, Updated date, and Stars.

We welcome feedback about these changes in issue 438322.

We added a new endpoint to the Groups API to list the groups a group has been invited to. This functionality complements the endpoint to list the projects that a group has been invited to, so you can now get a complete overview of all the groups and projects that your group has been added to. The endpoint is rate-limited to 60 requests per minute per user.

Thank you @imskr for this community contribution!

In GitLab 16.1, we introduced the Kubernetes pod list and detail views. However, you still had to use third-party tools for an in-depth analysis of your workloads. GitLab now ships with a log streaming view for pods and containers, so you can quickly check and troubleshoot issues across your environments without leaving your application delivery tool.

Discussions on GitLab issues can get busy. GitLab helps you manage these conversations by raising a to-do item for comments that are relevant to you, and automatically resolves the item when you take an action on the issue.

Previously, when you took action on a thread in the issue, all to-do items were resolved, even if you were mentioned in several different threads. Now, GitLab resolves only the to-do item for the thread you interacted with.

You can import projects to GitLab from other SCM solutions. However, it was difficult to know if project items were imported or created on the GitLab instance.

With this release, we've added visual indicators to items imported from GitHub, Gitea, Bitbucket Server, and Bitbucket Cloud where the creator is identified as a specific user. For example, merge requests, issues, and notes.

Previously, when using GitLab for Jira Cloud app, if you deleted a branch in GitLab, that branch still appeared in Jira development panel. Selecting that branch caused a 404 error on GitLab.

From this release, branches deleted in GitLab are removed from the Jira development panel.

GitLab offers many settings across projects, groups, the instance, and for yourself personally. To find the setting you're looking for, you often have to spend time clicking through many different areas of the UI.

With this release, you can now search for project settings from the command palette. Try it out by visiting a project, selecting Search or go to..., entering command mode with >, and typing the name of a settings section, like Protected tags. Select a result to jump right to the setting itself.

In GitLab 17.2, wiki page titles are separate from their paths. In previous releases, if a page title changed, the path would also change, which could cause links to the page to break. Now, if a wiki page's title changes, the path remains unchanged. Even if a wiki page path changes, an automatic redirect is set up to prevent broken links.

GitLab 17.2 adds several enhancements to how wikis display the sidebar. Now, a wiki displays all pages in the sidebar (up to 5000 pages), displays a table of contents (TOC), and provides a search bar to quickly find pages.

Previously, the sidebar lacked a TOC, making it challenging to navigate to sections of a page. The new TOC feature helps to see the page structure clearly, as well as navigate quickly to different sections, greatly improving usability.

The addition of a search bar makes discovering content easier. And because the sidebar now displays all pages, you can seamlessly browse an entire wiki.

Issues, tasks, incidents, requirements, objectives, and key results all trigger payloads under the Issues Events webhook category. Until now, there has been no way to quickly determine the type of object that triggered the webhook within the event payload. This release introduces an object_attributes.type attribute available on payloads within the Issues events, Comments, Confidential issues events, and Emoji events triggers.

Back in September 2021, git-lfs 3.0.0 released support for using SSH as the transfer protocol instead of HTTP. Prior to git-lfs 3.0.0, HTTP was the only supported transfer protocol which meant using git-lfs at GitLab was not possible for some users. With this release, we're very excited to offer the ability to enable support for SSH over HTTP as the transfer protocol for git-lfs.

Thank you to Kyle Edwards and Joe Snyder for this contribution!

You can now sort the pipeline schedules list by description, ref, next run, created date, and updated date.

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

What's new:

• GitLab Runner fleeting plugin for AWS EC2 instances (GA)
• Permit configuration of Runner livenessProbe and readinessProbe
• Ability to enable and disable the umask 0000 command for the Kubernetes executor
• Support for Red Hat OpenShift 4.16 for the GitLab Runner Operator

Bug Fixes:

• Gitlab Runner upgrade removes all cache volumes

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

The Terraform module registry now displays Readme files! With this highly requested feature, you can transparently document the purpose, configuration, and requirements of each module.

Previously, you had to search other sources for this critical information, which made it difficult to properly evaluate and use modules. Now, with the module documentation readily available, you can quickly understand a module's capabilities before you use it. This accessibility empowers you to confidently share and reuse Terraform code across your organization.

GitLab now supports the OAuth 2.0 device authorization grant flow. This flow makes it possible to securely authenticate your GitLab identity from input constrained devices where browser interactions are not an option. This makes the device authorization grant flow ideal for users attempting to use GitLab services from headless servers or other devices with no, or limited, UI. Thank you John Parent for your contribution!

Administrators can now run a script that identifies dates when multiple access tokens expire. You can use this script in combination with other scripts on the token troubleshooting page to identify and extend large batches of tokens that might be approaching their expiration date, if token rotation has not yet been implemented.

The OAuth authorization screen now more clearly describes the authorization you are granting. It also includes a "verified by GitLab" section for applications that are provided by GitLab. Previously, the user experience was the same, regardless of whether an application was provided by GitLab or not. This new functionality provides an extra layer of trust.

The administrator setup experience for a new install of GitLab has been streamlined and made more secure. The initial administrator root email address is now randomzied, and administrators are forced to change this email address to an account that they can access. Previously, this step could have been delayed, and an administrator might forget to change the email address.

In GitLab 17.2, we've added support for the Users API to the GitLab Data Connector, which is available in the Snowflake Marketplace app. You can now stream user data from self-managed GitLab instances to Snowflake using the Users API.

In GitLab 15.3 we introduced the compare_to keyword for rules:change. This made it possible to define the exact ref to compare against. Beginning in GitLab 17.2, you can now use CI/CD variables with this keyword, making it easier to define and reuse compare_to values in multiple jobs.