15.0

GitLab 15.0 Release

GitLab 15.0 released with WYSIWYG for Wiki, container scanning in all tiers

GitLab 15.0 with container scanning now available on all tiers, internal notes for issues epics, linking external organizations and contacts to issues, GitLab SaaS runners on macOS and much more!

Today, we are excited to announce the release of GitLab 15.0 with container scanning in all tiers, internal notes, better links to external organizations and contacts, and much more!

These are just a few highlights from the 40+ improvements in this release. Read on to check out all of the great updates below.

Along with these exciting new features, there are a few breaking changes in 15.0.

Want to learn more about where we're headed from Product leadership? Register now for the GitLab 15 launch event!

To preview what's coming in next month’s release, check out our Upcoming Releases page, which includes our 15.1 release kickoff video.

GitLab MVP badge

MVP This month's Most Valuable Person (MVP) is awarded to Lee Tickett

Lee has been instrumental in building the foundation for our CRM feature. He has contributed to 7 issues and many more merge requests to deliver this over the past few milestones. This foundation allows users to set up and link organizations and contacts to issues directly in GitLab making it easier to track customer requests and deliver on their work.

On top of being involved in all of the work to get the CRM delivered, Lee continued to contribute to many other areas of GitLab improving documentation, GitLab CI templates for dotNET, and Mermaid diagram usability.

Lee is really a prolific contributor and we’re so excited about all the work he continues to contribute to GitLab. THANK YOU!

15.0 Key improvements released in GitLab 15.0

GitLab 15.0 includes a few exciting improvements to speed up your workflow in the WYSIWYG Markdown editor for your wikis.

First, you’ll find no more un-styled, monochrome code blocks: choose from over 100 languages in the dropdown list above the code block so your CSS, YAML, and Python code are distinct from each other with accurate syntax highlighting. The code blocks will even inherit your preferred syntax highlighting theme. You can also quickly copy the code block to your clipboard for use in your code editor of choice.

You’ll also find working with links and media in the WYSIWYG editor easier than ever. Previously, you had to select from the editing toolbar to change a selected link or image on your wiki page, with some edits requiring you to delete the link or image and re-create it. Editing links and images is now easier, with a new popover menu that appears when you select a link or attached image. From the menu you can quickly edit a link’s destination URL or description, copy the link or image to your clipboard, or even remove the link or image from the page.

Edit code blocks, links, and media inline in the WYSIWYG editor

Advanced Search is compatible with OpenSearch

Advanced Search is compatible with OpenSearch

OpenSearch is an open source Elasticsearch fork. Prior to GitLab 15.0, Advanced Search was not compatible with OpenSearch. If you used AWS-managed services, you had to use older versions of Elasticsearch. You can now take full advantage of OpenSearch for Advanced Search.

Advanced Search is compatible with OpenSearch

Plan and schedule issues with automated iteration cadences

Plan and schedule issues with automated iteration cadences

In GitLab 14.10 and earlier, groups supported only one set of iterations. It made it difficult for different teams that worked in a single group to have autonomy with scheduling and tracking their issues from iteration to iteration. To improve this, we’re adding the ability for a group to manage multiple sets of concurrent iterations with iteration cadences. This allows each team to have control over the start day and duration of each iteration in their iteration cadence.

The day-to-day management of iterations is now much more efficient too. When you create a new iteration cadence, select the first day of your first iteration, how many weeks each iteration should be, and how many upcoming iterations GitLab should maintain for you. You can also optionally enable unfinished issues to automatically roll over from one completed iteration to the next. After a cadence is created, GitLab automatically creates the specified number of upcoming iterations.

You can now also scope an issue board or issue list to an iteration.

All existing iterations in a group will be converted to an iteration cadence with no changes to underlying iteration data. Additionally, to better support future enhancements to iterations, such as iteration velocity and volatility and capacity planning, we’ve deprecated the ability to manually create and delete individual iterations and will remove this functionality in 16.0. Learn how to migrate to automated iteration cadences.

Plan and schedule issues with automated iteration cadences

Internal notes

Internal notes

In many cases, organizations want to keep issues and epics public, but apply stricter governance to conversations within them. For example, when using GitLab issues as part of Service Desk workflows, organizations may want to make core details about an issue public, but not to expose customer-specific confidential data broadly.

With internal notes, you can redact discussions with internal or customer data that should only be visible to certain users, while keeping the core details about an issue public. Internal notes in issues or epics can only be seen by the issue author, assignee, and group or project members with at least the Reporter role.

Thanks @leetickett for collaborating with our team on this feature!

Internal notes

GitLab 15.0 introduces the first MVC toward managing and billing external customers from GitLab. With the customer relations management (CRM) feature, you can:

  • Create organizations and contacts.
  • Set a default bill rate for an organization.
  • Add contacts to organizations.
  • Link contacts to issues with the /add_contacts quick action.
  • View issues associated with a given contact or all contacts belonging to an organization.

The customer relations feature is not enabled by default, and can only be managed from a top-level group. If you want to help shape the future direction for customer relations management within GitLab, please contribute to this issue.

Thanks @leeticket for the dozens of contributions and countless hours spent leading this effort!

Container Scanning available in all tiers

Container Scanning available in all tiers

Container Scanning helps developers to easily find known security vulnerabilities in dependencies that are installed in their container images. With GitLab 15.0, we are making the basic Container Scanning features available in every GitLab tier.

Use nested CI/CD variables with environments in pipeline configuration

Use nested CI/CD variables with environments in pipeline configuration

Using CI/CD variables with the environment keyword in your CI/CD configuration is great, because it lets you create environments dynamically. While this is already a powerful feature, there were still some limitations, because you could not use nested variables to define environments.

Starting in GitLab 15.0, you can nest variables inside other variables, and have them all expand the way you expect. This makes dynamic environments even more powerful due to the increased flexibility!

Use nested CI/CD variables with environments in pipeline configuration

15.0 Other improvements in GitLab 15.0

Audit changes to group IP allowlist

Audit changes to group IP allowlist

In previous versions of GitLab, changes to the group IP allowlist did not generate audit events. This made it difficult to know who changed what, and when, when multiple people were modifying the allowlist. Now, any changes to group IP allowlists generate audit events.

Migration support for project releases milestones

Migration support for project releases milestones

We continue to add support for more release metadata to GitLab migration. In GitLab 15.0, we’ve added project releases milestone. This metadata will help you migrate more of the release data without needing to manually copy over missing release attributes.

Revoke a personal access token without PAT ID

Revoke a personal access token without PAT ID

In previous versions of GitLab, personal access tokens could be deleted only by the ID. Because none of the endpoints return an ID from a given value, you couldn’t delete a personal access token if you only had the token value.

You can also now use the personal_access_tokens/self endpoint to revoke a PAT with a single request. The endpoint revokes the PAT used to make the request, making it easy to quickly revoke PATs in case of a leak.

Thank you Hemanth Krishna for your contribution!

Reorganize issue description list items with drag and drop

Reorganize issue description list items with drag and drop

Issue descriptions are used to capture a lot of different types of information such as checklists, outlines, and implementation details. You can now easily reorganize a description’s list items by dragging and dropping them without having to edit and save the full description.

Reorganize issue description list items with drag and drop

Configure wiki visibility for groups

Configure wiki visibility for groups

GitLab 15.0 brings finer-grained control over group-level wiki visibility that matches the options already available on project-level wikis.

Now you can choose whether your wiki is visible to everyone with access to the group, restrict its access to just group members, or even disable visibility completely. Group administrators can find these options in the Group Settings page.

Configure wiki visibility for groups

Display usage of shared runners in user namespaces

Display usage of shared runners in user namespaces

Tracking monthly CI/CD usage for public projects was hard, especially across multiple projects in a namespace. You could not easily see what project or projects were using shared runners the most.

Now shared SaaS runner usage for each user namespace is displayed along with the CI/CD minutes on the Usage Quota page. You can see how much each project has used the shared runners and how minutes usage is trending over time.

Display usage of shared runners in user namespaces

Project-level Secure Files in open beta

Project-level Secure Files in open beta

Previously, it was difficult to use binary files in your CI/CD pipelines because CI/CD variables could only contain text values. This made it difficult to make use of profiles, certificates, keystores, and other secure information, which are important for teams building mobile apps.

Today we are releasing Project-level Secure Files in open beta. Now you can upload binary files to projects in GitLab, and include those files in CI/CD jobs to be used in the build and release processes as needed. Secure Files are stored outside of version control and are not part of the project repository.

Please leave us your feedback about your experience with this feature in the feedback issue.

View more details about each runner

View more details about each runner

Previously, if wanted an at-a-glance view of a runner’s relevant information, you had to switch between screens or even use the API to retrieve the details. Now, administrators can view the runner’s executor, architecture, and platform on the runner’s detail view. These details can help you quickly determine essential details, which are critical for troubleshooting issues or managing day-to-day operations and maintenance tasks.

View more details about each runner

Approve deployments from the Environments detail page

Approve deployments from the Environments detail page

Prior to this release, you had the ability to approve or reject a deployment only through the overview Environments page. In 15.0, you can now approve or reject a pending deployment approval from the environment’s detail page.

Approve deployments from the Environments detail page

Cluster support for Kubernetes 1.22

Cluster support for Kubernetes 1.22

If you use Kubernetes, GitLab wants to ensure you have full functionality when you upgrade your clusters to the most recent Kubernetes version. While many of you use GitLab to deploy your Kubernetes clusters, until recently there was no official support for Kubernetes 1.21 and 1.22. This release brings full support for all of the Kubernetes-related features from those versions.

REST API for the agent for Kubernetes

REST API for the agent for Kubernetes

GitLab now includes a REST API to register and manage the agent for Kubernetes. You can view the details about your agents, register new agents, and manage agent tokens. This API supplements the existing GraphQL API. You can use the REST API to automate the full agent lifecycle.

Thank you @tuxtimo for your contributions!

Set Environment tier via API

Set Environment tier via API

Previously, the only way to set the deployment_tier for an Environment was to use the keyword in the .gitlab-ci.yml file. In 15.0, we have added an endpoint to the Environment API to set the tier.

The agent server for Kubernetes enabled by default in the Helm chart

The agent server for Kubernetes enabled by default in the Helm chart

The first step for using the agent for Kubernetes in self-managed instances is to enable the agent server, a backend service for the agent for Kubernetes. In GitLab 14.8 we enabled the agent server for Omnibus based installations. The feature has matured in the past few months, so we are now making the agent server enabled by default in the GitLab Helm chart as well to simplify setup for GitLab administrators. Besides being enabled by default, the agent server accepts various configuration options to customize it according to your needs.

Dependency scanning support for poetry.lock files

Dependency scanning support for poetry.lock files

Dependency Scanning now supports parsing of poetry.lock files. This allows users to scan Python dependencies for vulnerabilities when those dependencies are managed by the Poetry package manager.

Semgrep-based SAST scanning available for early adoption

Semgrep-based SAST scanning available for early adoption

You can now switch to Semgrep-based scanning for many languages in GitLab SAST. Semgrep-based scanning brings significantly faster analysis, reduced usage of CI minutes, and more customizable scanning rules compared to existing language-specific analyzers. As of GitLab 15.0, it supports C, Go, Java, JavaScript, Python, and TypeScript.

In a future release, we’ll change GitLab SAST to use only Semgrep-based scanning by default for supported languages, and we’ll remove the language-specific analyzers that also scan them. (This change was previously scheduled for GitLab 15.0; work to complete it is tracked in this deprecation issue.)

You can now choose to disable deprecated language-specific analyzers early and use Semgrep-based scanning instead before we change the default behavior. We’ve updated documentation to explain the transition, including guidance on when to make the change in your pipelines.

GitLab advisory data included in container scanning results

GitLab advisory data included in container scanning results

GitLab Container Scanning relies on information from its analyzers to report vulnerabilities. Ensuring that databases have the most up to date information is important to make sure scans are returning both accurate and timeline results.

GitLab provides our own advisory database, which sources additional information that may not be updated in common sources. These external sources are tracked and information is updated daily. GitLab now includes this information when the trivy analyzer used with in GitLab Container Scanning, to help ensure that the most comprehensive and up-to-date vulnerability data is available for identifying vulnerabilities.

In GitLab Ultimate, the proprietary GitLab Advisory Database is used for these scans. In the Free and Premium tiers, the open source GitLab Advisory Database (Open Source Edition) is used, which is a one-month time-delayed clone of the proprietary database.

These databases give you access to additional threat information identified by GitLab’s research team, even if that threat data has not yet been added to other public databases.

Geo’s initial Git repository replication is 27% faster

Geo’s initial Git repository replication is 27% faster

Git is at the heart of every GitLab project and one of Geo’s key capabilities is to replicate Git repositories to secondary sites. Every time a new project is created, Geo needs to replicate the repository as fast as possible.

In this release, we’ve optimized the underlying Git commands used by Geo. By using git clone instead of git fetch for initial git repository replication performance increased by 27%.

Omnibus improvements

Omnibus improvements

  • GitLab 15.0 includes Mattermost 6.6, whose newest release includes triggers and actions on channel messages and the general availability of Apps Framework. This version also includes security updates and an upgrade from earlier versions is recommended.
  • In GitLab 15.0, the new default version of PostgreSQL for new installs will be 13.6. Users currently on PostgreSQL 12 will stay on PostgreSQL 12, unless the user manually upgrades the PostgreSQL version. New installs can opt into PostgreSQL 12 during installation if desired.
  • Starting with GitLab 15.0, the AES256-GCM-SHA384 SSL cipher will not be allowed by NGINX by default. If you require this cipher (for example, if you use AWS’s Classic Load Balancer), you can add the cipher back to the allowlist.
  • Starting in Gitlab 15.0, when the version of PostgreSQL changes, postgresql and geo-postgresql services are automatically restarted. Restarting PostgreSQL services causes downtime, due to the temporary unavailability of the database for operations. While this restart is mandatory for proper functioning of the database services, you might want more control over when the PostgreSQL is restarted. For that purpose, you can choose to skip the automatic restarts as part of gitlab-ctl reconfigure and manually restart the services. Users can also skip automatic restarts as part of GitLab 15.0 upgrade.

Follow or unfollow someone from the user popup

Follow or unfollow someone from the user popup

Before this release, you could only follow or unfollow a GitLab user from their user profile. It was difficult to know if you were following a specific user unless you viewed the user’s profile.

In this release, thanks to Kev’s contribution, you can quickly follow and unfollow users through the user popup, no matter where you are in your GitLab workflow: in notes, issues, and more. This reduces the extra step of going to the user’s profile, and makes it easier to follow and unfollow other GitLab users.

Follow or unfollow someone from the user popup

New audit events for merge settings

New audit events for merge settings

GitLab now records additional audit events when changes are made to merge request settings. Specifically, audit events are now created when changes are made to:

  • Merge commit message template
  • Squash commit message template
  • Default description template for merge requests
  • Status checks being added, changed, or deleted
  • Merge method
  • Merge options
  • Squash commits when merging settings
  • Merge checks
  • Merge suggestions

These audit events can help you know that the settings and default configurations for your merge requests have been put in place correctly and that they have not been changed. You might need to know this to pass audits that require separation of duties.

If these templates or checks are changed, the audit events show you when your workflow was changed to a non-compliant state and the related information to that change. You can have a retrospective to understand the specific change, when it was made, and who was involved. You can then take any remedial action as needed or work with the teams that made the change.

Support for failed status checks

Support for failed status checks

External status checks are great for integrating with third-party systems, but they didn’t always properly communicate the state of the check. You might wait for pending to update, but the external check had failed and there was no way to communicate this.

You can now set an external status check to an explicit failed (or passed) state. Previously, external checks could only be in pass or pending state. The new failure state allows you to very clearly indicate that something needs to be done to allow the external check to pass.

Support for failed status checks

Users with the Reporter role can manage iterations and milestones

Users with the Reporter role can manage iterations and milestones

We’ve changed the permissions necessary to create, edit, and delete milestones and iterations from the Developer to Reporter role. This change better reflects the typical day-to-day Reporter responsibilities of managing and tracking planning timeboxes.

Multiple account support for GitLab Workflow in VS Code

Multiple account support for GitLab Workflow in VS Code

When setting up GitLab Workflow for VS Code, you must provide a token to authenticate to GitLab. This token authenticates you to your GitLab instance as a particular user for checking out code, seeing issues, reviewing merge requests, and more.

In GitLab Workflow 3.44, you can now use multiple tokens to authenticate to the same GitLab instance. This can be great for users who have both work and personal accounts, or accounts with separated duties.

We’ve also improved key storage for tokens, which will now be stored in VS Code’s SecretStorage, and is backed by your operating system keychain.

Multiple account support for GitLab Workflow in VS Code

GitLab Runner 15.0

GitLab Runner 15.0

We’re also releasing GitLab Runner 15.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:

Bug Fixes:

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

Show instance CI/CD limits in /help

Show instance CI/CD limits in /help

Instance Administrators can set a number of CI/CD limits in the Admin Area of their instance. It is hard for users without administrator access to know what the limits are, especially when pipelines are failing because they bump into limits they didn’t know existed.

Now the CI/CD related limits for the instance can be seen on the instance configuration page found at /help/instance_configuration. Thanks to @wwwjon for this contribution!

Access and Verify actions for environments

Access and Verify actions for environments

Previously, when using environments, only one keyword existed to specify that a job is executing a task that does not trigger a deployment, or create or stop an environment. This environment: action: prepare keyword was intended for jobs that assist in preparing an environment. However, there are many other deployment related tasks beyond preparing an environment, and users have overloaded the prepare keyword to perform these tasks. In 15.0, we have added two new keywords to execute tasks that require access to environment scope variables. In the .gitlab-ci.yaml file, you can now add a generic environment: action: access keyword for a broad set of use cases and environment: action: verify when specifically needing to verify the results during a deployment.

Automatically create release notes from annotated tags

Automatically create release notes from annotated tags

Previously, release note descriptions were empty when a release is created. With this update, when creating releases in the UI based on a tag, you can now easily include that tag’s message in the release notes. You can select the checkbox option in the UI to append the tag’s message to the release notes section of the release. This change makes it easier to incorporate important content such as a changelog or feature list into the published release.

Automatically create release notes from annotated tags

Multiple on_stop jobs for an environment

Multiple on_stop jobs for an environment

Previously, when using the environment:on_stop keyword, only one job could be specified and run as part of closing an environment. In GitLab 15.0, you can now specify multiple jobs with the on_stop keyword in your .gitlab-ci.yaml file that run in parallel when closing an environment to enable more complex environment teardown procedures.

Release API endpoint for groups

Release API endpoint for groups

We have added a new endpoint for the Groups API that enables you to retrieve releases for all projects within a group. This allows users or consumers of the API to conveniently get a holistic view of releases at the group level. The endpoint supports sorting by created_at date and pagination.

Terraform CI/CD template authenticates to Terraform module registry

Terraform CI/CD template authenticates to Terraform module registry

If you use Terraform, you can use the module registry to store your infrastructure modules and streamline your developer experience. GitLab ships with a set of Terraform CI/CD templates that support all of the GitLab features out-of-the-box and can help even inexperienced Terraform users get started quickly.

Previously, if you used the Terraform module registry, you needed to authenticate to the registry as part of a custom CI job, even if you used the Terraform CI/CD templates. Thanks to community contributions from @willianpaixao and @terorie, the built-in Terraform template now automatically looks in the CI job to retrieve authorized Terraform modules from the registry.

Dependency path information

Dependency path information

Dependency Scanning can now identify the shortest dependency path for findings identified in your project. This is visible in the Evidence section when viewing details for a vulnerability, and in the Location column of the Dependency List page. This improvement makes it easier for users to triage the finding, and to determine the steps to resolve the vulnerability.

Secure and Protect analyzer major version update

Secure and Protect analyzer major version update

Secure and Protect features now use a new major version for all analyzers. This version change clearly distinguishes between analyzers that are:

Schema validation makes GitLab analyzers and third-party integrations more reliable.

If you use the GitLab-managed CI/CD templates, you don’t have to take any action. The analyzers used in your pipelines automatically update to the latest version.

If you use a custom template, or if you’ve pinned analyzer versions, you need to update your CI/CD job definition to either remove the pinned version or update to the latest major version.

All new bug fixes and features will now be released in the new analyzer major versions. These improvements won’t be available in the deprecated analyzer versions because we don’t backport bug fixes and new features; see GitLab’s maintenance policy. As required, security patches will be backported within the latest 3 minor GitLab releases.

The new versions of all analyzers are:

  • API Security: version 2
  • Container Scanning: version 5
  • Coverage-guided Fuzz Testing: version 3
  • Dependency Scanning: version 3
  • Dynamic Application Security Testing (DAST): version 3
  • Infrastructure as Code (IaC) Scanning: version 2
  • License Scanning: version 4
  • Secret Detection: version 4
  • Static Application Security Testing (SAST): version 3 for all analyzers, except version 4 for the gosec analyzer

Static Analysis analyzer updates

Static Analysis analyzer updates

GitLab Static Analysis includes many security analyzers that the GitLab Static Analysis team actively manages, maintains, and updates. The following analyzer updates were published during the 15.0 release milestone. These updates bring additional coverage, bug fixes, and improvements.

  • Brakeman analyzer updated to version 5.2.2. See CHANGELOG for details.
    • Update handling of conditionals, reflection, and nil values
    • Add additional String methods for SQL injection check
    • Update parser for Ruby 3.1 support
  • Secrets analyzer updated. See CHANGELOG for details.

If you include the GitLab-managed SAST template (SAST.gitlab-ci.yml), you don’t need to do anything to receive these updates. However, if you override or customize your own CI/CD template, you need to update your CI/CD configurations. To remain on a specific version of any analyzer, you can pin to a minor version of an analyzer. Pinning to a previous version prevents you from receiving automatic analyzer updates and requires you to manually bump your analyzer version in your CI/CD template.

For previous changes, see last month’s updates.

Scan result policies listed under MR approval settings

Scan result policies listed under MR approval settings

GitLab 15.0 now lists scan result policies in your project’s merge request approval settings area. You can view, in one location, all merge request approval rules that apply to the project, with scan result policies displayed next to the merge request approval rules.

Scan result policies listed under MR approval settings

GitLab chart improvements

GitLab chart improvements

  • In GitLab 15.0, the GitLab agent server (KAS), which is required to manage the GitLab agent for Kubernetes, is enabled by default. Enabling the GitLab agent server by default allows you to benefit from the GitLab agent for Kubernetes as an active in-cluster component for solving any GitLab ↔ Kubernetes integration tasks.
  • Starting with GitLab 15.0, the AES256-GCM-SHA384 SSL cipher will not be allowed by NGINX by default. If you require this cipher (for example, if you use AWS’s Classic Load Balancer), you can add the cipher back to the allowlist.

Advanced Search is compatible with Elasticsearch 8

Advanced Search is compatible with Elasticsearch 8

Elasticsearch 8 is the current version of Elasticsearch by Elastic. Previously, you could not use Elasticsearch 8 for Advanced Search. You had to use older versions instead. Starting in 15.0, you can use Elasticsearch 8 for Advanced Search.

  • If you use Elasticsearch 7.x, you must upgrade to GitLab 15.0 before upgrading to Elasticsearch 8.
  • If you use Elasticsearch 6.8, upgrade to any Elasticsearch 7.x version before upgrading to GitLab 15.0.

Bug fixes, performance improvements, and UI improvements

Bug fixes, performance improvements, and UI improvements

At GitLab, we’re dedicated to providing the best possible experience for our users. With every release, we work tirelessly to fix bugs, improve performance, and enhance UI. Whether you’re one of the over 1 million users on GitLab.com or using our platform elsewhere, we’re committed to making sure your time with us is smooth and seamless.

Click the links below to see all the bug fixes, performance enhancements, and UI improvements we’ve delivered in 15.0.

Deprecations Deprecations

New deprecations and the complete list of all features that are currently deprecated can be viewed in the GitLab documentation. To be notified of upcoming breaking changes, subscribe to our Breaking Changes RSS feed.

  • PostgreSQL 12 deprecated
  • Removals and breaking changes Removals and breaking changes

    The complete list of all removed features can be viewed in the GitLab documentation. To be notified of upcoming breaking changes, subscribe to our Breaking Changes RSS feed.

    • OAuth tokens without expiration
    • Querying usage trends via the `instanceStatisticsMeasurements` GraphQL node
    • OAuth implicit grant
    • Tracing in GitLab
    • Logging in GitLab
    • htpasswd Authentication for the container registry
    • Test coverage project CI/CD setting
    • GraphQL permissions change for Package settings
    • Background upload for object storage
    • Secure and Protect analyzer major version update
    • Dependency Scanning Python 3.9 and 3.6 image deprecation
    • Out-of-the-box SAST support for Java 8
    • Container Network and Host Security
    • SAST support for .NET 2.1
    • Secure and Protect analyzer images published in new location
    • Request profiling
    • Deprecate feature flag PUSH_RULES_SUPERSEDE_CODE_OWNERS
    • Vulnerability Check
    • Support for gRPC-aware proxy deployed between Gitaly and rest of GitLab
    • GraphQL ID and GlobalID compatibility
    • Optional enforcement of PAT expiration
    • Optional enforcement of SSH expiration
    • `projectFingerprint` in `PipelineSecurityReportFinding` GraphQL
    • Retire-JS Dependency Scanning tool
    • External status check API breaking changes
    • Required pipeline configurations in Premium tier
    • Elasticsearch 6.8
    • `artifacts:reports:cobertura` keyword
    • Sidekiq metrics and health checks configuration
    • `apiFuzzingCiConfigurationCreate` GraphQL mutation
    • CI/CD job name length limit
    • bundler-audit Dependency Scanning tool
    • Legacy approval status names from License Compliance API
    • `type` and `types` keyword in CI/CD configuration
    • `dependency_proxy_for_private_groups` feature flag
    • `promote-db` command from `gitlab-ctl`
    • `pipelines` field from the `version` field
    • `promote-to-primary-node` command from `gitlab-ctl`
    • Update to the container registry group-level API
    • Known host required for GitLab Runner SSH executor
    • Value Stream Analytics filtering calculation change
    • `Versions` on base `PackageType`
    • Support for SLES 12 SP2
    • Changing an instance (shared) runner to a project (specific) runner
    • `defaultMergeCommitMessageWithDescription` GraphQL API field
    • GitLab Serverless
    • Dependency Scanning default Java version changed to 17
    • Legacy database configuration
    • Audit events for repository push events
    • Outdated indices of Advanced Search migrations
    • OmniAuth Kerberos gem
    • Important notes on upgrading to GitLab Important notes on upgrading to GitLab 15.0


      Changelog Changelog

      Please check out the changelog to see all the named changes:

      Installing Installing

      If you are setting up a new GitLab installation please see the download GitLab page.

      Updating Updating

      Check out our update page.

      Questions? Questions?

      We'd love to hear your thoughts! Visit the GitLab Forum and let us know if you have questions about the release.

      GitLab Subscription Plans GitLab Subscription Plans

      • Free

        Free-forever features for individual users

      • Premium

        Enhance team productivity and coordination

      • Ultimate

        Organization wide security, compliance, and planning

      Try all GitLab features - free for 30 days

      We want to hear from you

      Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.

      Share your feedback

      Take GitLab for a spin

      See what your team could do with The DevSecOps Platform.

      Get free trial

      Have a question? We're here to help.

      Talk to an expert
      Edit this page View source