chore(deps): update dependency gitlab-org/gitlab-foss to v17 - autoclosed
This MR contains the following updates:
Package | Update | Change |
---|---|---|
gitlab-org/gitlab-foss | major |
v16.11.3 -> v17.0.1
|
Release Notes
gitlab-org/gitlab-foss (gitlab-org/gitlab-foss)
v17.0.1
v17.0.0
: GitLab 17.0
GitLab chart improvements (self-managed only): Cloud Native Installation
The GitLab Operator is now available for production use for cloud-native hybrid installations. See the installation documentation before adopting the GitLab Operator.
Support for a fallback to BusyBox images when you specify custom BusyBox values (
global.busybox
) is removed. Support for BusyBox-based init containers was deprecated in GitLab 16.2 (Helm chart 7.2) in favor of a common GitLab-based init image.Support for
gitlab.kas.privateApi.tls.enabled
andgitlab.kas.privateApi.tls.secretName
is also removed. You must useglobal.kas.tls.enabled
andglobal.kas.tls.secretName
instead.The deprecated queue selector and negate options are removed from the Sidekiq chart.
Linux package improvements (self-managed only): Omnibus Package
CentOS Linux 7 will reach end of life on June 30, 2024. This makes GitLab 17.1 the last GitLab version in which we can provide packages for CentOS 7.
Two database mode is available in Beta (self-managed only): Cell
Currently, most self-managed customers only utilize a single database. In order to ensure that the setup between GitLab.com and self-managed is the same, we ask self-managed customers to migrate and run decomposed by default. In 16.0, two database connections became the default for self-managed installations. In 17.0, we will end support for single database connections on self-managed, but we will continue supporting single databases with two connections until 19.0. In 17.0, we release two database mode as a limited Beta, with the goal to make running decomposed generally available by 19.0. Migration remains optional in 17.0, but needs to be performed before upgrading to 19.0.
The migration requires downtime. Self-managed customers can use a tool that executes this migration with some downtime. We introduced a new
gitlab-ctl
command that allows you to upgrade your single-database GitLab instances to a decomposed setup. This setup contains commands that will work with our Linux package. The actual migration (copying the database) is part of a rake task in the GitLab project.
Private shared group members are listed on Members tab for all members: Groups & Projects
Previously, when a public group or project invited a private group, the private group was listed only in the Groups tab of the Members page, and private members were not visible to members of the public group. To enable better collaboration between members of these groups, we are now also listing all invited group members in the Members tab, including members from private invited groups. The source of membership will be masked from members that do not have access to the private group. However, the source of membership will be visible to users who have at least the Maintainer role in the project or Owner role in the group, so that they can manage members in their project or group. If the current user viewing the Members tab is unauthenticated or not a member of the group or project, they will not see the private group members. We hope this change will make it easier for group and project members to understand at a glance who has access to a group or project.
Members page displays members from invited groups: Groups & Projects
Previously, members of groups that were invited to a group or project were visible only in the Groups tab of the Members page. This meant users had to check both the Groups and Members tabs to understand who has access to a certain group or project. Now, shared members are listed also in the Members tab, giving a complete overview of all the members that are part of a group or project at a glance.
Increase Kubernetes agent authorization limit: Continuous Delivery
With the GitLab agent for Kubernetes, you can share a single agent connection with a group. We aim to support a single agent across a large multi-tenant cluster. However, you might have faced a limitation on the number of connection sharing. Until now, an agent could be shared with only 100 projects and groups using CI/CD, and 100 projects and groups using the
user_access
keyword. In GitLab 17.0, the number of projects and groups you can share with is raised to 500.If you need to run multiple agents in a cluster, we would like to hear your feedback in issue 454110.
Support for GitLab agent for Kubernetes in FIPS mode (self-managed only): Continuous Delivery
From GitLab 17.0, you can install GitLab in FIPS mode with the agent for Kubernetes components enabled. Now, FIPS-compliant users can benefit from all the Kubernetes integrations with GitLab.
Track fast-forward merge requests in deployments: Continuous Delivery
In past releases, merge requests were tracked in a deployment only if the project's merge method was Merge commit or Merge commit with semi-linear history. From GitLab 17.0, merge requests are tracked in deployments, including in projects with the merge method Fast-forward merge.
Manage
Import from Bitbucket Cloud by using REST API: Importers
In this milestone, we added the ability to import Bitbucket Cloud projects by using the REST API.
This can be a better solution for importing a lot of projects than importing by using the UI.
Re-import a chosen project relation by using the API: Importers
When importing projects from export files with many items of the same type (for example, merge requests or pipelines), sometimes some of those items weren't imported.
In this release, we 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 (issues, merge requests, pipelines, or milestones).
Indicate that items were imported using direct transfer: Importers
You can migrate GitLab groups and projects between GitLab instances by using direct transfer.
Until now, imported items were not easily identifiable. With this release, we've added visual indicators to items imported with direct transfer, where the creator is identified as a specific user:
- Notes (system notes and user comments)
- Issues
- Merge requests
- Epics
- Designs
- Snippets
- User profile activity
Plan
Design Management features extended to Product teams: Design Management
GitLab is expanding collaboration by updating our permissions. Now, users with the Reporter role can access Design Management features, enabling product teams to engage more directly in the design process. This change simplifies workflows and accelerates innovation by inviting broader participation from across your organization.
Milestones and iterations visible on issue boards: Team Planning
We've improved issue boards to offer you clearer insights into your project's timeline and phases. Now, with milestone and iteration details directly visible on issue cards, you can easily track progress and adjust your team's workload on the fly. This enhancement is designed to make your planning and execution more efficient, keeping you in the loop and ahead of schedule.
Create
Commit signing for GitLab UI commits (self-managed only): Source Code Management
Previously, web commits and automated commits made by GitLab could not be signed. Now you can configure your self-managed instance with a signing key, a committer name, and email address to sign web and automated commits.
Verify
CI/CD Catalog with components and inputs now generally available: Pipeline Composition
The CI/CD Catalog is now generally available. As part of this release, we're also making CI/CD components and inputs generally available.
With the CI/CD Catalog, you gain access to a vast array of components created by the community and industry experts. Whether you're seeking solutions for continuous integration, deployment pipelines, or automation tasks, you'll find a diverse selection of components tailored to suit your requirements. You can read more about the Catalog and its features in the following blog post.
You're invited to contribute CI/CD components to the Catalog and help expand this new and growing part of GitLab.com!
Add a group to the CI/CD job token allowlist: Secrets Management
Introduced in GitLab 15.9, the CI/CD job token allowlist prevents unauthorized access from other projects to your project. Previously, you could allow access at the project level from other specific projects only, with a maximum limit of 200 total projects.
In GitLab 17.0, you can now add groups to a project's CI/CD job token allowlist. The maximum limit of 200 now applies to both projects and groups, meaning a project allowlist can now have up to 200 projects and groups authorized for access. This improvement makes it easier to add large numbers of projects associated with a group.
Enhanced context control with the rules:exists
CI/CD keyword: Pipeline Composition
The
rules:exists
CI/CD keyword has default behaviors that vary based on where the keyword is defined, which can make it harder to use with more complex pipelines. When defined in a job,rules:exists
searches for specified files in the project running the pipeline. However, when defined in aninclude
section,rules:exists
searches for specified files in the project hosting the configuration file containing theinclude
section. If configuration is split over multiple files and projects, it can be hard to know which exact project will be searched for defined files.In this release, we have introduced
project
andref
subkeys torules:exists
, providing you a way to explicitly control the search context for this keyword. These new subkeys help you ensure accurate rule evaluation by precisely specifying the search context, mitigating inconsistencies, and enhancing clarity in your pipeline rule definitions.
Semantic version ranges for published CI/CD components: Pipeline Composition
When using a CI/CD Catalog component, you might want to have it automatically use the latest version. For example, you don't want to have to manually monitor all the components you use and manually switch to the next version every time there is a minor update or security patch. But using
~latest
is also a bit risky because minor version updates could have undesired behavior changes, and major version updates have a higher risk of breaking changes.With this release, you can opt to use the latest major or minor version of a CI/CD component. For example, specify
2
for the component version, and you'll get all updates for that major version, like2.1.1
,2.1.2
,2.2.0
, but not3.0.0
. Specify2.1
and you'll only get patch updates for that minor version, like2.1.1
,2.1.2
, but not2.2.0
.
Standardized CI/CD Catalog component publishing process: Pipeline Composition
We have been hard at work on CI/CD components, including making the process of releasing components to the CI/CD Catalog a consistent experience. As part of that work, we've made releasing versions from a CI/CD job with the
release
keyword and therelease-cli
image the only method. All improvements to the release process will apply to this method only. To avoid breaking changes introduced by this restriction, make sure you always use the latest version of the image (release-cli:latest
) or at least a version greater thanv0.17
. The Releases option in the UI is now disabled for CI/CD component projects.
Always run after_script
commands for canceled jobs: Continuous Integration (CI)
The
after_script
CI/CD keyword is used to run additional commands after the mainscript
section of a job. This is often used for cleaning up environments or other resources that were used by the job. However,after_script
commands did not run if a job was canceled.As of GitLab 17.0,
after_script
commands will always run when a job is canceled. To opt out, see the documentation.
GitLab Runner 17.0: GitLab Runner Core
We’re also releasing GitLab Runner 17.0 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:
The list of all changes is in the GitLab Runner CHANGELOG.
Package
Filter package registry UI for packages with errors: Package Registry
You can use the GitLab package registry to publish and download packages. Sometimes, packages fail to upload due to an error. Previously, there was no way to quickly view packages that failed to upload. This made it challenging to get a holistic view of your organization's package registry.
Now you can filter the package registry UI for packages that failed to upload. This improvement makes it easier to investigate and resolve any issues you encounter.
Secure
Streamlined SAST analyzer coverage for more languages: SAST
GitLab Static Application Security Testing (SAST) now scans the same languages with fewer analyzers, offering a simpler, more customizable scan experience.
In GitLab 17.0, we've replaced language-specific analyzers with GitLab-managed rules in the Semgrep-based analyzer for the following languages:
- Android
- C and C++
- iOS
- Kotlin
- Node.js
- PHP
- Ruby
As announced, we've updated the SAST CI/CD template to reflect the new scanning coverage and to remove language-specific analyzer jobs that are no longer used.
Monitor
Multiple external participants for Service Desk: Service Desk
Sometimes there is more than one person involved in resolving a support ticket or the requester wants to keep colleagues up-to date on the state of the ticket.
Now you can have a maximum of 10 external participants without a GitLab account on a Service Desk ticket and regular issues.
External participants receive Service Desk notification emails for each public comment on the ticket, and their replies will appear as comments in the GitLab UI.
Simply use the quick actions
/add_email
andremove_email
to add or remove external participants with a few keystrokes.You can also configure GitLab to add all email addresses from the
Cc
header of the initial email to the Service Desk ticket.You can tailor all Service Desk email templates to your liking, using markdown, HTML, and dynamic placeholders. An unsubscribe link placeholder is available to make it easy for external participants to opt out of a conversation.
Govern
Identify sessions initiated by Admin Mode (self-managed only): User Management
As an instance administrator, when you use multiple browsers or different computers, it is difficult to know which sessions are in Admin Mode and which aren't. Now, administrators can go to User Settings > Active Sessions to identify which sessions use Admin Mode.
Thank you Roger Meier for your contribution!
Automatic deletion of unverified secondary email addresses: User Management
If you add a secondary email address to your user profile and do not verify it, that email address is now automatically deleted after three days. Previously, these email addresses were in a reserved state and could not be released without manual intervention. This automatic deletion reduces administrator overhead and prevents users from reserving email addresses that they do not have ownership of.
Configuration
-
If you want to rebase/retry this MR, check this box
This MR has been generated by Renovate Bot. The local configuration can be found in the SI Renovate Bot repository.