gitlab-org/gitlab-foss v17.1.0

on GitLab

Gitlab 17.1 includes packages for supporting Ubuntu Noble 24.04.

You can now create badge links and image URLs using four new placeholders:

• %{project_namespace} - referencing the full path of a project namespace
• %{group_name} - referencing the group name
• %{gitlab_server} - referencing the group's or project's server name
• %{gitlab_pages_domain} - referencing the group's or project's domain name

Thank you @TamsilAmani for this community contribution!

You can now create badge links and image URLs using a %{latest_tag} placeholder. This placeholder references the latest tag that was published for a repository.

Thank you @TamsilAmani for this community contribution!

You can now use the new GraphQL API field User.contributedProjects to list the projects a user has contributed to.

Thank you @yasuk for this community contribution!

Previously, when using the Members API, you could add members to groups and projects only by their user ID. With this release, you can now add members also by their username.

Thank you @imskr for this community contribution!

We have updated the sorting and filtering functionality of the group and project Explore pages. The filtering bar is now wider for better readability.

In the Explore page for projects, you can now use standardized sorting options that include Name, Created date, Updated date, and Stars, and a navigation element to sort in ascending or descending order. The language filter has moved to the filter menu. A new Inactive tab displays archived projects for a more focused search. Additionally, you can use a Role filter to search for projects you are the Owner of.

In the Explore 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 issue 438322.

Previously, a group's or project's general settings displayed only permitted visibility levels. This view often confused users who tried to understand why the other options were not available, and could lead to information being displayed incorrectly. The new view shows all visibility levels, greying out the options that are not available for selection. In addition, a popover gives further context about why an option is not available. For example, a visibility level could be unavailable because an administrator restricted it, or it would cause a conflict with a project's or parent group's visibility setting.

We hope these changes help you resolve the conflicts in selecting your desired visibility option. Thank you @gerardo-navarro for this community contribution!

Do you need to be notified when a new release is posted? GitLab now provides an RSS feed for releases. You can subscribe to a release feed with the RSS icon on the project release page.

Thanks to Martin Schurz for the contribution!

Until now cancelling a running direct transfer migration required access to a Rails console.

In this release, we've added the ability for Administrators to cancel a migration by using the REST API.

When importing projects from export files with many items of the same type (for example, merge requests or pipelines), sometimes some of those items aren't imported.

In this release, we've added an API endpoint that re-imports a named relation, skipping items that have already been imported. The API requires both:

• A project export archive.
• A type. Either issues, merge requests, pipelines, or milestones.

Until now, inherited memberships were not imported reliably when migrating by direct transfer. This meant that inherited members of projects were imported as direct members.

From this release, GitLab now first migrates group membership before migrating project memberships. This replicates the inherited memberships on the source GitLab instance.

In GitLab 16.11, we introduced the ability to add custom headers when you create or edit a webhook.

With this release, you can now use the GitLab REST API to set custom webhook headers.

Thanks to Niklas for this community contribution!

The wiki feature in GitLab 17.1 provides a more unified and efficient workflow:

• Easier and quicker cloning with a new repository clone button. This improves collaboration, and speeds up access to the wiki content for editing or viewing.
• A more obvious delete option in a more discoverable location. This reduces the time spent searching for it, and minimizes potential errors or confusion when managing wiki pages.
• Allowing empty pages to be valid, improving flexibility. Create empty placeholders when you need them. Focus on better planning and organization of wiki content, and fill in the empty pages later.

These enhancements improve ease of use, discoverability, and content management in your wiki's workflow. We want your wiki experience to be efficient and user-friendly. By making cloning repositories more accessible, relocating key options for better visibility, and allowing for the creation of empty placeholders, we're refining our platform to better meet your users' needs.

GitLab 17.1 enhances the handling of high-resolution images, enabling them to be downscaled during upload. Previously, images displayed in their original size, resulting in suboptimal display quality. This improvement ensures large images don't break the visual flow of the pages they are included in.

Previously, moving media in the rich text editor required you to copy and paste each item manually. This often slowed down the inclusion of media in issues, epics, and wikis. In GitLab 17.1, you can now drag and drop media in the rich text editor, significantly enhancing efficiency during editing.

GitLab can be configured to enforce client authentication with SSL certificates. However, the GitLab Pages service was incompatible with that feature, because it couldn't be configured to use client certificates, and calls to the internal API were rejected.

From GitLab 17.1, you can configure a client certificate for GitLab Pages. This allows you to enable client authentication with the GitLab API, strengthening the security of your GitLab instance.

GitLab 17.1 introduces a significant enhancement to wiki page redirects. When you rename a wiki page, anyone trying to access the old page is automatically redirected to the new page, ensuring all existing links remain functional. This improvement streamlines the workflow for managing page name changes and enhances the overall knowledge management experience.

In GitLab 17.1 we've improved the Pages user interface. Improvements include more efficient use of screen space. These UI improvements are focused on improving user experience and efficiency when managing Pages.

You'll now notice a smoother experience when updating issues on boards! Changes you make in the sidebar will instantly appear on the board itself, no more refreshing required. This reactive boards experience streamlines your workflow, allowing you to quickly make updates while seeing them reflected in real-time.

With this release, you can now set time estimates and record time spent on tasks with a quick action or in the time tracking widget in the task's sidebar. Time spent on a task can be viewed with the task's time tracking report.

When you review code in a merge request and comment on a line of code, GitLab includes a few lines of the diff in the email notification to participants. Some organizational policies treat email as a less secure system, or might not control their own infrastructure for email. This can present risks to IP or access control of source code.

New settings are available in groups and projects to enable organizations to remove diff previews from merge request emails. This can help ensure that sensitive information isn't available outside of GitLab.

A gigantic thank you to Joe Snyder for contributing this!

In earlier versions of GitLab, some customers needed an autoscaling solution for GitLab Runner on virtual machine instances on public cloud platforms. These customers had to rely on the legacy Docker Machine executor or custom solutions stitched together by using cloud provider technologies.

Today, we're pleased to announce the general availability of the GitLab Runner Autoscaler. The GitLab Runner Autoscaler is composed of GitLab-developed taskscaler and fleeting technologies and the cloud provider plugin for Google Compute Engine.

Manual jobs can be used to trigger highly critical operations in your CI pipeline, such as deploying to production. With this release, you can now configure a manual job to require confirmation before it runs. Use manual_confirmation with when: manual to display a confirmation dialog in the UI when a job is run manually. Requiring confirmation for manual jobs provides an additional layer of security and control.

Special thanks to Phawin for this community contribution!

To better control who can override user-defined variables, we are introducing the ci_pipeline_variables_minimum_role project setting. This new setting provides greater flexibility than the existing restrict_user_defined_variables setting. You can now restrict override permissions to no users, or only users with at least the Developer, Maintainer, or Owner roles.

Today we're releasing GitLab Runner 17.1! 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 GCP Compute Engine

Bug Fixes:

• Runner helper images missing the entry point

The list of all changes is in the GitLab Runner change log.

GitLab now officially supports model registry in beta as a first-class concept. You can add and edit models directly via the UI, or use the MLflow integration to use GitLab as a model registry backend.

A model registry is a hub that helps data science teams manage machine learning models and their related metadata. It serves as a centralized location for organizations to store, version, document, and discover trained machine learning models. It ensures better collaboration, reproducibility, and governance over the entire model lifecycle.

We think of the model registry as a cornerstone concept that enables teams to collaborate, deploy, monitor, and continuously train models, and are very interested in your feedback. Please feel free to drop us a note in our feedback issue and we'll get back in touch!

Administrators can now search users by partial email address in the User overview of the Admin Area. For instance, you can filter users by a specific email domain to find all users from a distinct institution. This feature is limited to administrators to prevent unprivileged users from accessing email addresses of other accounts.

Thanks @zzaakiirr for this community contribution!

Both project Owners and Maintainers with direct membership now receive email notifications when their project access tokens are close to expiring. Previously, only project Maintainers received this notification. This helps keep more people informed about upcoming token expiration.

Thank you Jacob Henner for your contribution!