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.
Epic parent
You can now easily manage your epic hierarchy by adding a parent directly from an epic, just as you would for an issue. This streamlined process gives you more flexibility in organizing your work, allowing you to quickly establish relationships between epics and maintain a clear structure for your projects.
Your administrator must enable the new look for epics.
Show iteration field on child items in epics, issues, and objectives
When viewing epic detail, planners need to be able to see which child issues are planned into iterations (sprints) and which are not yet planned. This will allow teams to more easily make sure that all defined work is slated into sprints.
For 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.
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!
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.
Epic health status
You can now easily communicate the progress of your projects with the new health status feature for epics. By setting the status to “On track,” “Needs attention,” or “At risk,” you’ll have a quick visual indicator of your epic’s health, allowing you to manage risk and keep stakeholders informed about the project’s overall status.
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.
Track time spent on epics
You can now track time directly in epics, giving you more granular control over your project’s time management. This new feature allows you to log time spent on different aspects of your project, helping you monitor progress, stay on schedule, and keep your budget in check as you work through sprints and milestones.
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.
GitLab MLOps Python Client Beta
Data scientists and Machine Learning engineers primarily work in Python environments, but integrating their machine learning workflows with GitLab’s MLOps features often requires context switching and understanding of GitLab’s API structure. This can create friction in their development process and slow down their ability to track experiments, manage model artifacts, and collaborate with team members.
The new GitLab MLOps Python client provides a seamless, Pythonic interface to GitLab’s MLOps features. Data scientists can now interact with GitLab’s experiment tracking and model registry capabilities directly from their Python scripts and notebooks. The client includes:
- GitLab Experiment Tracking: Easily track machine learning experiments within GitLab.
- Model Registry Integration: Register and manage models in GitLab’s model registry.
- Experiment Management: Create and manage experiments directly from the client.
- Run Tracking: Initiate and monitor training runs with ease.
This integration allows data scientists to focus on model development while automatically capturing their ML lifecycle metadata in GitLab. The Python client works seamlessly with existing ML workflows and requires minimal setup, making GitLab’s MLOps features more accessible to the data science community.
We welcome the wider Python and data science community to contributions and share feedback directly in our project’s repository
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.
