15.7

GitLab 15.7 Release

GitLab 15.7 released introducing the GitLab CLI and with browser-based DAST GA

GitLab 15.7 released introducing the GitLab CLI, browser-based DAST GA, support for GitOps deployments from outside the default branch, and much more!

We are excited to announce the release of GitLab 15.7, which introduces the new GitLab CLI, general availability of browser-based DAST, support for GitOps deployments from outside the default branch, and much more!

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

We thank the wider GitLab community for the 190+ contributions they provided to GitLab 15.7! At GitLab, everyone can contribute and we couldn't have done it without you!

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

GitLab MVP badge

MVP This month's Most Valuable Person (MVP) is Niklas van Schrick

Niklas has continually iterated on a manual, painful process for the Technical Writing (TW) team until ultimately making that process simple and automated.

Niklas worked to refine how to run batch updates to the CODEOWNERS file and the related issues. Read the full story of Niklas’s impact.

Additionally, Niklas is playing a fundamental role in building GitLab’s achievement system and has had at least one MR merged every milestone since 14.3!

15.7 Key improvements released in GitLab 15.7

Introducing the GitLab CLI

Introducing the GitLab CLI

The command line is one of the most important tools in a software engineer’s toolkit and the majority of their process and work revolve around tools available there. They customize their CLI with styles and extend it through applications to ensure maximum efficiency while performing tasks. The CLI is the backbone of scripts and workflows developers depend on to complete their work.

To support more developers where they’re already working, we’ve adopted the open source project glab, which will form the foundation of GitLab’s native CLI experience. The GitLab CLI brings GitLab together with Git and your code, with no application or tab switching required.

You can read about our adoption of glab, our partnership with 1Password, and how to contribute to the project in our blog post.

A special thank you to Clement Sam for creating glab and trusting us with its future.

Introducing the GitLab CLI

Share CI/CD access to the agent within a personal namespace

Share CI/CD access to the agent within a personal namespace

The GitLab agent for Kubernetes provides a more secure solution for managing your clusters with GitLab CI/CD. You can use a single agent with multiple projects and groups by sharing access to the agent connection. In previous releases, you could not share access with personal namespaces. This release adds support for CI/CD connection sharing to personal namespaces. You can now use a single agent from any of the projects under your personal namespace.

Share CI/CD access to the agent within a personal namespace

Support GitOps deployments from outside the default branch

Support GitOps deployments from outside the default branch

In previous releases, the GitLab agent for Kubernetes was restricted to manifest files stored on your main branch. This model had known limitations. For example, you couldn’t store the manifests of your next release on a release branch and test them in an ephemeral environment.

Now, you can specify a Git reference along with the manifest project configuration. Besides the main branch, you can sync your manifest files from another branch, a git tag, or a specific commit.

Support GitOps deployments from outside the default branch

Sign commits with your SSH key

Sign commits with your SSH key

Signing commits just got a lot simpler. Use SSH keys to sign commits, and provide others with confidence that a Verified commit was authored by you.

Previous methods for signing commits required a GPG key or an X.509 certificate, neither of which can be used to sign in to GitLab. Adding support for commit signing with SSH keys now makes it possible to reuse your authentication key pair to also sign your commits. If you already authenticate into GitLab with an SSH key, add three lines of code to your local Git configuration and all your future commits will be signed.

By default, all SSH keys currently in your profile can be used for both authentication and signing commits. To use a key for only one of the purposes, upload a new key.

Experience the Web IDE Beta and Remote Development

Experience the Web IDE Beta and Remote Development

We are thrilled to announce the availability of the Web IDE Beta, our next-generation web editor based on Visual Studio Code that delivers powerful new features, a more flexible and familiar interface, and the ability to connect directly to a Remote Development environment. Paired with a cloud runtime, the Web IDE Beta enables more advanced real-time development workflows. Take a look at just some of the new features available today!

The Web IDE Beta is so powerful we’re making it the default Web IDE experience for GitLab.com, and we’re eager for your feedback. The Web IDE will continue to be available while we iterate on the Beta. To stop using the Web IDE Beta, go to your user preferences and select the Opt out of the Web IDE Beta checkbox.

Self-managed instances have access to the Web IDE Beta where it is behind a feature flag disabled by default in GitLab 15.7.

Learn more about the Web IDE Beta and what’s coming next in our recent blog post.

Self-managed support for the GitLab for Jira Cloud app

Self-managed support for the GitLab for Jira Cloud app

For self-managed GitLab, we’re excited to announce support for the GitLab for Jira Cloud app!

With this release, you can link your self-managed GitLab instance to Jira Cloud and enable the Jira development panel. This feature supports syncing updates from smart commits, merge requests, branches, builds, deploys, and feature flags back into the Jira development panel. You can pair the GitLab for Jira Cloud app with your basic Jira integration.

For more information, see Connect the GitLab for Jira Cloud app for self-managed instances.

If you use Jira Server or Jira Data Center, you should use the Jira DVCS Connector.

Self-managed support for the GitLab for Jira Cloud app

Retry a manual job with updated variables

Retry a manual job with updated variables

When running manual jobs, users can specify the extra CI/CD variables to use in the job. However, if you wanted to retry the same job, you always had to use the same variables as the first time. If you wanted to run the job with different variables, you had to run a new pipeline.

In this release, we have added the ability to specify variables every time you run a manual job, including when retrying the job. This allows for greater flexibility and convenience as you can retry a manual job as often as you like with a different set of variables in every run.

Browser-based DAST general availability

Browser-based DAST general availability

After being available in Beta since GitLab 13.2, our proprietary browser-based DAST analyzer is now being released for general availability in GitLab 15.7.

This new analyzer has been developed completely in-house and makes use of a browser to authenticate, crawl, and scan web applications for vulnerabilities. Traditional DAST analyzers scan using a proxy-based approach to intercept requests and analyze them for vulnerabilities. Because of this, running DAST scans on applications that utilize modern JavaScript frameworks or are single page applications has been extremely difficult. Often, you do not get the full coverage of the application that you would expect. With the browser-based approach, we are able to execute JavaScript directly in the browser, as a user would, to ensure that your entire application is scanned for vulnerabilities. Using the new analyzer, we are able to cover more of the pages in an application, as well as reduce the number of false positives reported.

At this time, we will not be switching the default analyzer used in the DAST.gitlab-ci.yml template to the browser-based analyzer, to allow users to make the switch manually and evaluate it for themselves. However, we plan to make the analyzer the default for all DAST scans at some point in the future. We encourage everyone to start to migrate to the new analyzer, so that when the default switch happens, it will not break any of your DAST scans. You can enable the browser-based analyzer by setting the DAST_BROWSER_SCAN to true in your .gitlab-ci.yml configuration. Please note that not all legacy DAST analyzer variables will be used with this new analyzer. Any unsupported legacy DAST variables configured in your .gitlab-ci.yml file will be ignored during the scan run.

We will continue to improve on this analyzer and have plans for many new features that the browser-based approach opens up to us. You can see our plans by looking at our browser-based DAST epic and its issues. We would love to get feedback on this epic (or any child issues) about what is most important for you in your DAST scans.

Browser-based DAST general availability

Select predefined CI/CD variables values from a dropdown list

Select predefined CI/CD variables values from a dropdown list

Previously, you could pre-fill CI/CD variables in the “Run pipeline” page, with a specific value. Unfortunately, if you had multiple options for the variable’s value, you still had to manually input the option you wanted. This was an error-prone process because you could easily input an invalid value, or just mistype it.

In this release, we’ve added the ability to set a list of values which are surfaced in a drop-down list in the “Run pipeline” page. Now you can define the exact list of values that are valid for each CI/CD variable when running a pipeline manually, greatly simplifying your workflow when using manually-triggered pipelines.

Select predefined CI/CD variables values from a dropdown list

Support the $ character in CI/CD variables

Support the $ character in CI/CD variables

Previously, using the $ character in a CI/CD variable always indicated the start of a reference another variable, which GitLab then tried to expand. As a result, you could not have a value with a $ as part of the string unless it was escaped, which can be confusing.

In this release, we are introducing a new setting for project, group, and instance CI/CD variables. You can now toggle whether or not GitLab interprets the CI/CD variable as a raw string, or treats a $ as the start of another variable that should be expanded.

Support the `$` character in CI/CD variables

15.7 Other improvements in GitLab 15.7

Audit event recorded when Admin Mode enabled

Audit event recorded when Admin Mode enabled

GitLab now records an audit event when an administrator enables Admin Mode. This is helpful for security-related auditing, because Admin Mode allows the user to elevate permissions and change instance level settings.

Cancel import of a project from GitHub

Cancel import of a project from GitHub

When importing GitHub projects into GitLab, you could not cancel an import that was in progress.

You can now cancel imports from GitHub that are pending or in progress. If the import has already started, the imported files are kept.

Group owners can list user’s email addresses using the API

Group owners can list user’s email addresses using the API

Group owners can now use the API to access the email addresses of any user provisioned by the group. A user is provisioned by the group when their account was created by SCIM, or by first sign in with SAML SSO for GitLab.com groups. Previously, group owners could only access this information if a user’s email addresses were public.

Option for single sign-on users to stay signed in

Option for single sign-on users to stay signed in

Users signed in to GitLab with single sign-on were signed out frequently. Now, these users can select the Remember me checkbox and stay signed in to GitLab for two weeks. When accessing group resources, users are redirected to their Identity Provider (IdP) once every 24 hours to verify the session. Depending on their IdP’s settings, users may have to re-authenticate to the IdP at this time.

Option for single sign-on users to stay signed in

Webhook push events support regular expressions

Webhook push events support regular expressions

For webhooks triggered on push events, you can now define a regex pattern that aligns with your branching strategy. For example, you can use ^(feature|hotfix)/ to allow any push to the feature or hotfix branch to trigger an event.

Webhook push events support regular expressions

Change the dimensions of images in Markdown

Change the dimensions of images in Markdown

Before this release, there were no controls for changing the size of images rendered within Markdown text areas. This often led to unwieldy images with no control over how much space they took up in descriptions and comments. You can now set the width and height of how images are rendered directly in Markdown by appending the {width=x height=y} attributes to the image reference. Sizes can be specified with pixels or percentages.

Variables in merge request description templates

Variables in merge request description templates

When creating a merge request, your organization may define merge request templates. These templates help make sure certain information is filled in, provide checklists for tasks, and more. However, they don’t contain any Git-level information that may be important for the merge request. This can make it challenging to provide commit message details, branch information, or even author information in a standardized and repeatable way.

Merge request description templates now support variables. Use these variables to build both business logic and important Git information, like commit and authoring info, into merge requests. Template variables ensure incoming merge requests always include the information your project requires, without tedious manual effort from contributors.

Thanks to David Barr for contributing this!

Variables in merge request description templates

GitLab Runner 15.7

GitLab Runner 15.7

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

Limit the number of project or group CI/CD variables to 200

Limit the number of project or group CI/CD variables to 200

If your instance has project or group maintainers adding too many CI/CD variables, it could use a lot of resources to process all the variables for each pipeline. To ensure your pipelines continue to run efficiently, we have added a limit of 200 variables per group or project.

Projects and groups that already have over 200 CI/CD variables can continue to run pipelines as before, but will not be able to add any more variables. We recommend reducing the number of CI/CD variables down to less than 200 per group or project for optimal performance.

Limit the number of project or group CI/CD variables to 200

Dependency scanning support for npm lockfileVersion 3

Dependency scanning support for npm lockfileVersion 3

GitLab Dependency Scanning now supports parsing and scanning dependencies stored in npm lockfiles where lockfileVersion: 3 is set.

See multiple Code Quality scan reports per pipeline

See multiple Code Quality scan reports per pipeline

GitLab Code Quality includes an MR widget, a pipeline report, and MR diff annotations to help you find and fix problems in your code. Many tools, including code scanners and linters for technical documentation, can output results in Code Quality’s open report format.

Previously, you could only see results from a single scan in the pipeline report and MR diff annotations. This made it harder to add custom scanning tools to your pipelines.

Now, all of the Code Quality views show results from all report artifacts saved in a pipeline.

This new feature was enabled in GitLab.com in GitLab 15.6. The feature flag is now also enabled by default for Self-Managed instances in GitLab 15.7 and newer.

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.7 release milestone. These updates bring additional coverage, bug fixes, and improvements.

  • Brakeman-based analyzer updated to version 5.3.1. See CHANGELOG for further details.
  • CodeClimate-based analyzer updated to version 0.87.3. We’ve also disabled a network call that checked for available updates. See CHANGELOG for further details.
  • Gitleaks-based analyzer updated to add a detection rule for systemd machine IDs and to exclude go.mod and go.sum files from scanning. See CHANGELOG for further details.
  • KICS-based analyzer updated to version 1.6.5. See CHANGELOG for further details. This version adds new rules, improves performance, and fixes a bug where some Terraform configurations could cause the analyzer to crash.
  • Kubesec-based analyzer updated to fix a bug for manifests with multiple objects. See CHANGELOG for further details.
  • NodeJSScan-based analyzer updated to version 0.3.4. See CHANGELOG for further details.
  • Semgrep-based analyzer updated to improve performance of built-in Python rules and support automatic vulnerability resolution. See CHANGELOG for further details.
  • Multiple analyzers updated to include git so that the analyzer can remove vulnerabilities in files that aren’t committed to the repository.

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.

GraphQL API for environment and deployment permissions

GraphQL API for environment and deployment permissions

We have exposed user permissions for environments and deployments through GraphQL. Now you can fetch user permissions for actions, such as update or destroy, for an environment or deployment via API.

Restrict access to a tunnel to specific environments

Restrict access to a tunnel to specific environments

You can use the CI/CD tunnel provided by the GitLab agent for Kubernetes to integrate your existing CI/CD workflows with your Kubernetes clusters. To save on resources and simplify maintenance, you can share a tunnel with multiple groups and projects.

In previous releases, if a CI/CD tunnel was available for a project, you could use it from all branches and in all environments. However, you could not restrict access to tunnels. Now, you can restrict access to tunnels to certain environments, or to environments that match a wildcard pattern.

Scan execution policy support for defining runner tags

Scan execution policy support for defining runner tags

Tags can now be defined in GitLab Scan Execution policies. This gives you the flexibility to specify which Runners will be used to execute your scan execution policy jobs.

Scan execution policy support for defining runner tags

In the search bar, you can now see autocomplete suggestions for users. When you select a user, their profile page appears.

Autocomplete suggestions for users in the global search bar

Omnibus improvements

Omnibus improvements

  • GitLab 15.7 includes Mattermost 7.5, with message threads in calls, new Board templates, Board filtering by text properties, Board metrics, Channel user last activity, and more. This version also includes security updates and upgrade from earlier versions is recommended.
  • GitLab 15.6 includes packages for openSUSE Leap 15.4.

Automatic disabling of failing webhooks

Automatic disabling of failing webhooks

To protect GitLab and users across the system from any potential abuse or misuse, we’ve implemented a feature to disable webhooks that fail consistently.

  • Webhooks that return response codes in the 5xx range are understood to be failing intermittently and are temporarily disabled. These webhooks are initially disabled for 1 minute, which is extended on each retry up to a maximum of 24 hours.
  • Webhooks that fail with 4xx errors are permanently disabled.

All project owners and maintainers are alerted in the app to investigate and re-enable any failed webhooks.

This feature is now available on GitLab.com and self-managed instances along with feature enhancements including handling cold starts.

Automatic disabling of failing webhooks

Disable personal access tokens with application setting

Disable personal access tokens with application setting

You can now disable personal access tokens (PATs) at the instance level with a new application setting. Previously, there was no option to disable PATs.

Mask sensitive portions of webhook URLs

Mask sensitive portions of webhook URLs

As you create webhooks to integrate with external services and receive GitLab data for event-driven workflows, you might have to supply callback URLs that include sensitive data. With this feature, you can now mask personal tokens, passwords, usernames, domains, and any other sensitive data when configuring your webhooks.

Mask sensitive portions of webhook URLs

Users cannot set a known weak password

Users cannot set a known weak password

When a user sets their password, the password is now checked against a list of known weak passwords. If the password matches an entry on the list, the user must choose a different one. This helps users choose more secure GitLab passwords.

Add spent time in the issue and merge request sidebar

Add spent time in the issue and merge request sidebar

Before 15.7, quick actions were the only way to add time spent on an issue or merge request. While this method works, it’s not intuitive for all users. To make recording time more efficient, you can now add time entries directly from the sidebar of an issue or a merge request.

Thanks for the contribution Marco Zille!

Add spent time in the issue and merge request sidebar

HTML comment support in the Content Editor

HTML comment support in the Content Editor

When you collaborate on a wiki page or blog post, you often come across inline HTML comments that are not meant to be rendered. Previously, the Content Editor would ignore these comments to reflect what the actual content would look like. The problem, however, was that making edits in the Content Editor could unexpectedly remove these comments from the file.

With this release, you can insert new HTML comments inline and edit comments already on the page. These comments appear in a way that indicates they won’t be rendered. This feature can help you manage longer wiki pages and is an important step towards editing issue descriptions and comments in future releases.

HTML comment support in the Content Editor

Add custom names to pipelines with workflow:name:

Add custom names to pipelines with workflow:name:

For some projects, the same pipeline can be configured to run differently for different variables or conditions, creating very distinct outcomes for successful pipelines. It can be hard for you to determine which version of that pipeline ran since there is no indication about the inputs used for that particular run. While labels like scheduled and API help, it is sometimes still difficult to identify specific pipelines.

Now you can set a pipeline name using the keyword workflow:name to better identify the pipeline with string, a CI/CD variable, or a combination of both.

Job execution status badge

Job execution status badge

The new job execution status badge in Admin Area > Runners and the {group_name} > CI/CD > Runners displays an at-a-glance indicator to determine if there are active jobs on a specific runner in the fleet. This iteration aims to simplify troubleshooting runner queue issues that impact time-to-result for CI builds.

Job execution status badge

Improved access control for the GitLab Package Registry

Improved access control for the GitLab Package Registry

When you configure your project, you can choose the visibility level and enable/disable project features and their permissions. For example, you could restrict access to Project members only for the repository, issues, merge requests, and more. Although you can control several features like this, you can only turn the GitLab Package Registry on and off. You can’t set the Package Registry visibility to project members only or everyone with access. This issue has made it difficult for you to create a central registry with approved, vetted packages for distribution throughout your organization. As a workaround, you’ve had to add everyone to the project, which introduces security risks.

To help make you more efficient, we’ve added feature-specific controls for the Package Registry. Now project Administrators and Owners have more flexibility and control over how they share the Package Registry. By default, the Package Registry visibility is set to project members only. For more information about what permissions are required to view, download, or update packages, refer to the Package Registry visibility permissions documentation.

On-demand DAST API GraphQL scans

On-demand DAST API GraphQL scans

As of GitLab 15.7, on-demand DAST API site profiles support configuring GraphQL APIs as the scan target. After selecting API as the site type, you can now select the GraphQL scan method and specify a GraphQL endpoint path. This ability has been available to DAST API scans in a CI/CD pipeline since we introduced the dast-api.gitlab-ci.yml template. With the switch from our legacy DAST API analyzer to our new analyzer for on-demand scans, we were able to add this functionality to our on-demand DAST API profiles.

See multiple findings in Code Quality changes view

See multiple findings in Code Quality changes view

We’ve improved GitLab Code Quality to make it easier to see and understand findings on merge requests when you’re reviewing changes. The Changes view on merge requests now supports showing more than one finding on each line, and you can now expand the findings to view them without continuing to hover over them.

This change is now active on GitLab.com. We plan to enable the feature flag by default for Self-Managed instances in GitLab 15.8.

See multiple findings in Code Quality changes view

Add finished_after filter to Deployments API

Add finished_after filter to Deployments API

With this update, you can filter the list of deployments in a project by finished_before or finished_after dates, to efficiently search for the relevant deployments in your workflow. Previously, filtering was allowed only by the updated dates.

Search for environments within folders

Search for environments within folders

With this release, we improved support for searching for environments. Previously, you needed to type out the complete name of an environment if it was in a folder. Now, the search bar matches environments’ names, even if they are nested.

Use the current project by default in GitOps configurations

Use the current project by default in GitOps configurations

When you install the agent, you typically create an agent without a configuration file. However, many features of the agent, including pull-based deployments, require a valid configuration.

In previous releases, pull-based deployments required you to specify the project where the manifest files are stored. If you had multiple projects, you needed a custom configuration file for each project. Now, you can omit the project ID and the agent will use the manifests in the current project. If your projects use the same conventions to store their manifests, you can use the same configuration file to set up an agent in every project.

Set default compliance framework for new projects in a group

Set default compliance framework for new projects in a group

In previous versions of GitLab, you could create a compliance framework for a group but needed to apply it to each new project individually.

Now you can set a compliance framework as the default framework to apply to new projects created in a group. Existing projects don’t have the default framework automatically applied.

Geo replicates dependency proxy

Geo replicates dependency proxy

Geo now replicates the dependency proxy pull-through cache, which means that a populated cache of images is available at the newly promoted site after a failover. You can now be confident in performing regular failovers and avoid hitting Docker Hub rate limits, thus compromising the operational capabilities of the promoted site. This will help deliver a seamless failover experience to the end users.

GitLab chart improvements

GitLab chart improvements

  • Cloud Native GitLab replaces alpine-certificates behaviors with gitlab-base in an upcoming release. To prevent differential behaviors between Alpine and Debian, and increase consistency across containers, we are going to build the pattern on gitlab-base. This means operational service containers will share a common root layer, which provides an efficiency boost to Pod instantiation time. The user impact of this, is that we will be changing the image name and tags used. We will maintain a mirrored tag for a short period.

Improved design for filtering global search results

Improved design for filtering global search results

Previously, global search scopes appeared as tabs below the search bar. This design wasn’t very intuitive and limited the number of available filtering options.

With this release, global search scopes now appear on the left sidebar. The new design makes it easier to filter results and allows for additional filtering options depending on content types. With this improvement, every page in global search results has a left sidebar and a consistent layout.

Improved design for filtering global search results

Specify custom NTP server when running Geo health check

Specify custom NTP server when running Geo health check

For Geo to function correctly, the clocks between Geo sites must be synchronized. When running Geo health checks, you can now specify a custom NTP server to override pool.ntp.org. This change lets you validate your clocks if you are using your own time server, or if you set up Geo in an offline environment and it can’t reach the default NTP server.

Bug fixes, performance improvements, and usability improvements

Bug fixes, performance improvements, and usability 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 usability. 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 usability improvements we’ve delivered in 15.7.

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.

  • DAST API scans using DAST template is deprecated
  • DAST API variables
  • DAST ZAP advanced configuration variables deprecation
  • DAST report variables deprecation
  • KAS Metrics Port in GitLab Helm Chart
  • POST ci/lint API endpoint deprecated
  • Shimo integration
  • Single merge request changes API endpoint
  • Support for REST API endpoints that reset runner registration tokens
  • Support for periods (.) in Terraform state names might break existing states
  • The Phabricator task importer is deprecated
  • The gitlab-runner exec command is deprecated
  • ZenTao integration
  • 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.

    • Flowdock integration
    • Important notes on upgrading to GitLab Important notes on upgrading to GitLab 15.7

      Container registry push events are rejected by the /api/v4/container_registry_event/events endpoint resulting in Geo secondary sites not being aware of updates to container registry images and subsequently not replicating the updates. Secondary sites may contain out of date container images after a failover as a consequence. This impacts versions 15.6.x and 15.7.0 - 15.7.2. If you’re using Geo with container repositories, you are advised to upgrade to GitLab 15.7.3 or 15.8.0 which contain a fix for this issue and avoid potential data loss after a failover.


      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 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

      Cover image licensed under Unsplash License

      Try all GitLab features - free for 30 days

      GitLab is more than just source code management or CI/CD. It is a full software development lifecycle & DevOps tool in a single application.

      Try GitLab Free
      Open in Web IDE View source