gitlab-org/gitlab-foss v17.9.0

on GitLab

Have you ever struggled to get an overview of your deployments within a project? You can now view recent deployment details in the environments list without having to expand each environment. For each environment, the list shows your latest successful deployment and, if different, your most recent deployment attempt.

Previously, a request to GitLab could only be authenticated as a single user. With composite identity, we have now made it possible to authenticate a request as a service account and a user simultaneously.
AI agent use cases often require permissions to be based on the user who initiated the tasks in a system, while simultaneously showing a distinct identity that's separate from the initiating user. A composite identity is our new identity principal, which represents an AI agent's identity. This identity is linked with the identity of the human user who requests actions from the agent.
Whenever an AI agent action attempts to access a resource, a composite identity token is used. This token belongs to a service account, and is also linked with the human user who is instructing the agent. The authorization checks that run on the token take into account both principals before granting access to a resource. Both identities need to have access to the resource, otherwise access is denied.
This new functionality enhances our ability to protect resources stored in GitLab.
For more information about how the composite identity for service accounts can be used, see the documentation.

Have you ever wondered how to implement GitOps best practices with GitLab? The new FluxCD component makes it easy. Use the FluxCD component to package Kubernetes manifests into OCI images and store the images in OCI-compatible container registries. You can optionally sign the images and trigger an immediate FluxCD reconciliation.

In this release, we added new Kubernetes Getting started guides that show you how to use GitLab to deploy applications to Kubernetes directly and with FluxCD. These easy-to-follow tutorials don't require in-depth Kubernetes knowledge to complete, so both novice and experienced users can learn how to integrate GitLab and Kubernetes.

To supplement the Kubernetes Getting started guides, we also included a series of recommendations for integrating GitLab into Kubernetes environments.

The certificate-based Kubernetes integration will be turned off on GitLab.com for all users between May 6, 2025 9:00 AM UTC and May 8, 2025 22:00 PM UTC, and will be removed from GitLab Self-Managed instances in GitLab 19.0 (expected in May 2026).

To help users migrate, we added a new cluster API endpoint that group Owners can query to discover any certificate-based clusters registered to a group, subgroup, or project. We also updated the migration documentation to provide instructions for different types of use cases.

We encourage all GitLab.com users to check if they are affected, and to plan their migrations as soon as possible.

Previously, you could manage project integrations from a group in the GitLab UI only. With this release, it's possible to manage these integrations with the REST API too.

Thanks to Van for their initial community contribution, which was subsequently picked up and completed by GitLab.

We're excited to announce expanded visibility for group sharing across GitLab. Previously, while you could see shared projects on a group's overview page, you couldn't see which groups your group had been invited to join. Now you can view both Shared projects and Shared groups tabs on the group overview page, giving you a complete view of how your groups are connected and shared throughout your organization. This makes it easier to audit and manage group access across your organization.

We welcome feedback about this change in epic 16777.

You can now add comments directly on wiki pages, transforming your documentation into an interactive collaboration space.

Comments and threads on wiki pages help teams:

• Discuss content directly in context.
  
• Suggest improvements and corrections.
  
• Keep documentation accurate and up-to-date.
  
• Share knowledge and expertise.
  

With wiki comments, teams can maintain living documentation that evolves alongside their projects through direct feedback and discussion.

You can now restrict GitLab Pages access at the group level. Group owners can enable a single setting to make all Pages sites in a group and its subgroups visible only to project members. This centralized control simplifies security management without modifying individual project settings.

You can now easily change the type of your work items, giving you the flexibility to manage your projects more efficiently.

The Work Items GraphQL API now includes additional query filters that let you filter by:

• Created, updated, closed, and due dates
  
• Health status
  
• Weight
  

These new filters give you more control when querying and organizing work items through the API.

In the past, if you wanted to delete older CI/CD pipelines, you could only do this through the API.

In GitLab 17.9, we have introduced a project setting that allows you to set a CI/CD pipeline expiry time.
Any pipelines and related artifacts older than the defined retention period are deleted.
This can help reduce the disk usage in projects that run lots of pipelines that generate large artifacts, and even improve overall performance.

We're also releasing GitLab Runner 17.9 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:

• Add health check for runner autoscaler instances
  
• Add histogram metrics for runner prepare stage duration
  
• Add support for custom service container names to the Kubernetes executor
  

Bug Fixes:

• GitLab Runner is unable to retrieve cache from S3 Express One Zone
  
• GitLab Runner on Kubernetes reports 'script_failure' instead of 'runner_system_failure' for AWS Spot instances
  

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

You can now use the self_rotate scope to rotate access tokens. This scope is available for personal, project, or group access tokens. Previously, this required two requests: One to obtain a new token, then another to perform the token rotation.

Thank you Stéphane Talbot and Anthony Juckel for your contribution!

Previously, when viewing your personal access tokens, the only usage information you could see was how many minutes ago the token was used. Now, you can also see up to the last seven IP addresses that the tokens were used from. This combined information can help you track where your token is being used.

Thank you Jayce Martin, Avinash Koganti, Austin Dixon, and Rohit Kala for your contribution!