gitlab-org/gitlab-foss v18.0.0

on GitLab

You can use the dashboard for Kubernetes to monitor your deployed applications. Until now, pods with container errors like CrashLoopBackOff or ImagePullBackOff were displayed with a "Pending" or "Running" status, which makes it difficult to identify problematic deployments without using kubectl.

In GitLab 18.0, error states in the UI show a specific container's status, similar to the kubectl output. Now, you can quickly identify and troubleshoot failing pods without leaving the GitLab interface.

The GitLab for Slack app now supports multiple workspaces for GitLab Self-Managed and GitLab Dedicated customers. Enabling multiple workspaces allows organizations with federated Slack environments to maintain seamless GitLab integrations across all their workspaces. To enable support for multiple workspaces, configure the GitLab for Slack app as an unlisted distributed app.

In GitLab 18.0, when you delete a top-level group, placeholder users associated with the group are deleted as well. If placeholder users are associated with other projects, they are only removed from the top-level group.
This way, unnecessary placeholder users are removed without disrupting the history or attributions of other projects.

• Breaking change: Support for PostgreSQL 14 and 15 has been removed. Make sure you are running PostgreSQL 16 before upgrading.
  
• Breaking change: The bundled Prometheus chart was updated from 15.3 to 27.11. Along with the Prometheus chart upgrade, the Prometheus version was updated from 2.38 to 3.0. Manual steps are required to perform the upgrade. If you have Alertmanager, Node Exporter, or Pushgateway enabled, you must also update your Helm values. For more information, see the migration guide.
  
• Breaking change: The default NGINX controller image was updated from version 1.3.1 to 1.11.2. If you're using the GitLab NGINX chart, and you have set your own NGINX RBAC rules, new RBAC rules must exist. For more information, see the upgrade guide for more information.
  

Project and group delayed deletion is now available for all GitLab users, including those on our Free tier. This essential safety feature adds a grace period (7 days on GitLab.com) before deleted groups and projects are permanently removed. This feature allows recovery from accidental deletions without complex recovery operations.

By making data safety a core feature, GitLab can help better protect your work against data loss events.

Delayed project deletion is now available for projects in user namespaces (personal projects). Previously, this safeguard against accidental data loss was only available for group namespaces. When you delete a project in your user namespace, it will now enter a "pending deletion" state for the duration configured in your instance settings (7 days on GitLab.com), rather than being immediately deleted. This creates a recovery window during which you can restore the project if needed.

We hope this enhancement provides greater peace of mind when managing your personal projects in GitLab.

We've added a new active parameter to our Groups and Projects REST APIs that simplifies filtering groups based on their status. When set to true, only non-archived groups or projects not marked for deletion are returned. When set to false, only archived groups or projects marked for deletion are returned. If the parameter is undefined, no filtering is applied. This enhancement helps you efficiently manage your workflows by targeting specific statuses through simple API calls.

Thank you @dagaranupam for adding this parameter to the Projects API.

We've made significant improvements to GitLab Query Language (GLQL) views. These improvements include support for:

• The >= and <= operators for all date types
  
• The View actions dropdown in views
  
• The Reload action
  
• Field aliases
  
• Aliasing columns to a custom name in GLQL tables
  

We welcome your feedback on this enhancement, and on GLQL views in general, in issue 509791.

GitLab provides templates for popular static site generators. We've taken a deep dive into available templates using a scoring framework, and refined the list to include only the most popular templates.

Refining templates available for GitLab Pages streamlines the website creation process. Use templates to launch professional-looking sites with minimal technical expertise. Enhanced templates also provide modern, responsive designs, eliminating the need for custom development work.

Previously, when working on code files, you had no visibility into who else might be modifying
the same file in other branches. This lack of awareness led to merge conflicts, duplicated work,
and inefficient collaboration.

Now you can easily identify all open merge requests that modify the file you're viewing in the
repository. This feature helps you:

• Identify potential merge conflicts before they happen.
  
• Avoid duplicating work that's already in progress.
  
• Improve collaboration by providing visibility into in-flight changes.
  

A badge displays the number of open merge requests modifying the file, and hovering over it
reveals a popover with the list of these merge requests.

The redesigned CI/CD analytics view transforms how your development teams analyze, monitor, and optimize pipeline performance
and reliability. Developers can access intuitive visualizations in the GitLab UI that reveal performance
trends and reliability metrics. Embedding these insights in your project repository eliminates context-switching
that disrupts developer flow. Teams can identify and address pipeline bottlenecks that drain productivity.
This enhancement leads to faster development cycles, improved collaboration, and data-driven confidence to optimize your
CI/CD workflows in GitLab.

We’re also releasing GitLab Runner 18.0 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 ConfigurationError and ExitCodeInvalidConfiguration to the GitLab Runner build error classifications
  
• Improve cloud provider error messages for failed cache uploads to cloud storage
  

Bug Fixes:

• GitLab Runner can use cached images even when disallowed
  

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

You can now choose to run Application Security Testing (AST) scanners in merge request (MR) pipelines.
To minimize the impact to your pipelines, this is as an opt-in behavior you can control.

Previously, the default behavior depended on whether you used the Stable or Latest CI/CD template edition to enable a scanner:

• In Stable templates, scan jobs ran in branch pipelines only. MR pipelines weren't supported.
  
• In Latest templates, scan jobs ran in MR pipelines when an MR was open, and ran in branch pipelines if there was no associated MR. You couldn't control this behavior.
  

Now, a new option, AST_ENABLE_MR_PIPELINES, allows you to control whether to run jobs in MR pipelines.
The default behavior for both Stable and Latest templates remains the same. Specifically:

• Stable templates continue to run scan jobs in branch pipelines by default, but you can set AST_ENABLE_MR_PIPELINES: "true" to use MR pipelines instead when an MR is open.
  
• Latest templates continue to run scan jobs in MR pipelines by default when an MR is open, but you can set AST_ENABLE_MR_PIPELINES: "false" to use branch pipelines instead.
  

This improvement affects all security scanning templates except for API Discovery (API-Discovery.gitlab-ci.yml), which currently defaults to MR pipelines.
We also changed the API Discovery template to align with other Stable templates in GitLab 18.0 and use branch pipeline by default.

Administrators can now choose if the maximum length of a user session is computed from the initial sign-in or from the last activity. Users are notified that the session is ending, but cannot prevent the session from expiring or extend the session. This feature is disabled by default.

Thank you John Parent for your contribution!

Pipeline security just got more flexible. Job tokens are ephemeral credentials that provide access to resources in pipelines. Until now, these tokens inherited full permissions from the user, often resulting in unnecessarily broad access capabilities.

With our new fine-grained permissions for job tokens beta feature, you can now precisely control which specific resources a job token can access within a project. This allows you to implement the principle of least privilege in your CI/CD workflows, granting only the minimal access necessary for each job to complete its tasks.

We're actively seeking community feedback on this feature. If you have questions, want to share your implementation experience, or would like to engage directly with our team about potential improvements, please visit our feedback issue.

Previously, you had to configure the integration to create Jira issues from vulnerabilities from the Project settings page.

You can now configure this integration from the project integrations API, which allows you to automate the setup.

In GitLab 18.0, we are enabling event-level product usage data collection from GitLab Self-Managed and GitLab Dedicated instances. Unlike aggregated data, event-level data provides GitLab with deeper insights into usage, allowing us to improve user experience on the platform and increase feature adoption. For detailed instructions on how to adjust data sharing settings, please refer to our documentation.