Track multiple to-do items in an issue or merge request
You can now keep track of multiple discussions and mentions within a single issue or merge request. With the new multiple to-do items feature, you’ll receive separate to-do items for each mention or action, ensuring you don’t miss important updates or requests for your attention. This enhancement helps you manage your work more effectively and respond to your team’s needs more efficiently.
Epic ancestors
Navigating your epic hierarchy just got easier with the redesigned Ancestry widget, now prominently displayed at the top of each epic in a breadcrumb-like format. You can quickly grasp the relationships between epics by seeing both immediate and ultimate parents at a glance, helping you maintain a clear overview of your project structure and easily move between related epics.
Your administrator must enable the new look for epics.
Webhooks for epics
Supercharge your workflow automation with the epic webhooks, allowing you to receive real-time updates in your preferred tools whenever changes occur in your epics. By integrating GitLab with your other services, you can enhance collaboration, stay on top of project developments, and streamline your processes without constantly switching between applications.
Your administrator must enable the new look for epics.
Pipeline limits available in GitLab Community Edition
Administrators can now control pipeline resource usage by setting CI/CD limits for their GitLab Community Edition installations. Previously, this feature was only available in GitLab Enterprise Edition.
Search for pods on the dashboard for Kubernetes
On the dashboard for Kubernetes, finding specific pods in large deployments can be time-consuming. A new search bar lets you quickly filter pods by name. The search works across all available pods, and you can combine it with status filters to find exactly the pods you need to monitor or troubleshoot.
Secret detection now includes remediation steps
It’s important to fix exposed secrets quickly to minimize the risk of attackers using exposed credentials to break into your systems. Proper remediation requires multiple steps beyond just removing the secret, such as rotating credentials and investigating potential unauthorized access. To help keep your systems secure, secret detection now includes specific remediation steps for each type of detected secret. This guidance helps you systematically address exposures and reduce the risk of security breaches. Remediation steps will appear on all vulnerabilities upon the completion of a pipeline.
Make skip_ci configurable for pipeline execution policies
We’ve introduced a new configuration option for Pipeline Execution Policies (PEPs) that allows for more flexibility in handling the [skip ci] directive. This feature addresses scenarios where certain automated processes, such as semantic releases, where it’s necessary to bypass pipeline execution while still ensuring critical security and compliance checks are performed.
To use this feature, set skip_ci to allowed: false in the pipeline execution policy YAML configuration or enable Prevent users from skipping pipelines the policy editor. Then, specify the users or service accounts that are allowed to use [skip ci]. By default all users will be blocked from skipping pipeline execution jobs unless they are excluded within the skip_ci configuration as an exception.
Example configuration:
yaml
pipeline_execution_policy:
- name: My pipeline execution policy with ci.skip exceptions
description: 'Enforces CI/CD jobs'
enabled: true
pipeline_config_strategy: inject_ci
content:
include:
- project: group-a/project1
file: README.md
skip_ci:
allowed: false
allowlist:
users:
- id: 75
Support multiple distinct approval actions in merge request approval policies
Previously, merge request approval policies supported only a single approval rule per policy, allowing for one set of approvers stacked with an “OR” condition. As a result, it was more challenging to enforce layered security approvals from varied roles, individual approvers, or separate groups.
With this update, you can create up to five approval rules for each merge request approval policy, allowing for more flexible and robust approval policies. Each rule can specify different approvers or roles and each rule is evaluated independently. For example, security teams can define complex approval workflows such as requiring one approver from Group A and one from Group B, or one from a specific role and another from a specified group, ensuring compliance and enhanced control in sensitive workflows.
Example uses of this improvement include:
Distinct role approvals: One approval from a Developer role and another from a Maintainer role.\
Role and group approvals: One approval from Developer or Maintainer and a separate approval from a member of the Security Group.\
Distinct group approvals: One approval from a member of the Python Experts Group and another separate approval from a member of the Security Group.
View subgroups and projects pending deletion
When you mark a group for deletion, you need visibility into all affected subgroups and projects. Previously, only the group marked for deletion displayed a “Pending deletion” label, but not their subgroups and projects, making it difficult to identify which content was scheduled for deletion.
Now, when a group is marked for deletion, all of its subgroups and projects will display a “Pending deletion” label. This improved visibility helps you quickly distinguish between active and soon-to-be deleted content across your entire group hierarchy.
Customizable colors for epics
You now have more flexibility in categorizing your epics with an expanded set of color options, including pre-existing values and custom RGB or hex codes. This enhanced visual customization allows you to easily associate epics with squads, company initiatives, or hierarchy levels, making it simpler to prioritize and organize your work on roadmaps and epic boards.
Your administrator must enable the new look for epics.
Primary domain redirect for GitLab Pages
You can now set a primary domain in GitLab Pages to automatically redirect all requests from custom domains to your primary domain. This helps maintain SEO rankings and provides a consistent brand experience by directing visitors to your preferred domain, regardless of which URL they initially use to access your site.
Use roles to define project members as Code Owners
You can now use roles as Code Owners in your CODEOWNERS file to manage role-based expertise and approvals more efficiently. Instead of listing individual users or creating groups, you can use the following syntax:
@@developers - References all users with the Developer role.@@maintainers - References all users with the Maintainer role.@@owners - References all users with the Owner role.
For example, add * @@maintainers to require approval from any maintainer for all changes in the repository.
This simplifies Code Owner management as team members join, leave, or change roles in your project. The CODEOWNERS file remains current without manual updates, because GitLab automatically includes all users who have the specified role.
Enhance security with protected container repositories
We’re thrilled to announce the rollout of protected container repositories, a new feature in GitLab’s container registry that addresses security and control challenges in managing container images. Organizations often struggle with unauthorized access to sensitive container repositories, accidental modifications, lack of granular control, and difficulties in maintaining compliance. This solution provides enhanced security through strict access controls, granular permissions for push, pull, and management operations, and seamless integration with GitLab CI/CD pipelines.
Protected container repositories offers value to users by reducing the risk of security breaches and accidental changes to critical assets. This feature streamlines workflows by maintaining security without sacrificing development speed, improves overall governance of the container registry, and provides peace of mind knowing that important container assets are protected according to organizational needs.
This feature and the protected packages feature are both community contributions from gerardo-navarro and the Siemens crew. Thank you Gerardo and the rest of the crew from Siemens for their many contributions to GitLab! If you are interesting in learning more about how Gerardo and the Siemens crew contributed this change, check out this video in which Gerardo shares his learnings and best practices for contributing to GitLab based on his experience as an external contributor.
View paused Flux reconciliations on the dashboard for Kubernetes
Previously, when you suspended Flux reconciliation from the dashboard for Kubernetes, there was no clear indicator of the suspended state. We’ve added a new “Paused” status to the existing set of status indicators, making it clear when Flux reconciliation is suspended and providing better visibility into the state of your deployments.
Enforce centralized workflow rules for the override_ci strategy
In pipeline execution policies, the override_ci strategy now supports the use of workflow rules to aid in policy enforcement for jobs defined in the policy, as well as jobs defined in the project’s configuration when using include:project. By defining workflow rules in the policy, you can filter out jobs executed by the pipeline execution policy based on particular rules, such as by configuring rules that prevent the use of branch pipelines in projects.
To isolate the use of workflow rules to target only jobs defined in your policy, the best practice is to define the rules for the job instead of globally in the policy. Alternatively, you can group jobs and rules using a separate include field.
Previously, when using the override_ci strategy, workflow rules could only be applied to jobs defined in the pipeline execution policy.
The inject_ci strategy remains unchanged and workflow rules can only be used to control when policy jobs are enforced, without affecting the project’s workflow rules.
Manage concurrency of scheduled scan execution pipelines
To improve the scalability of global scheduled scan execution policies, we have introduced a new capability to configure a time window in a scan execution policy. The time_window property defines the time period in which the policy creates and executes new schedules to ensure optimal performance.
To use the new property, update your policy using YAML mode and follow the time_window schema. You can provide a value in seconds for the window of time in which the schedules should run. For example, 86400 for a 24 hour time window. Then supply the distribution: random field and value to enforce the schedules to execute at random times across the defined time window.
Project creation protection for groups now includes Owners
Project creation can be restricted to specific roles in a group using the Allowed to create projects setting. The Owner role is now available as an option, enabling you to restrict new project creation to users with the Owner role for the group. This role was previously unavailable in the selection options.
Thank you @yasuk for this community contribution!
