Jun 22, 2019 - Jeremy Watson  

GitLab 12.0 released with Visual Reviews and Dependency List

GitLab 12.0 released with Visual Reviews, Dependency List, and much more!

Dev, Sec, and Ops

GitLab 12.0 marks a key step in our journey to create an inclusive approach to DevSecOps, empowering "everyone to contribute".

For the past year, we've been on an amazing journey, collaborating and creating a solution that brings teams together. There have been thousands of community contributions making GitLab more lovable.

We believe everyone can contribute, and we’ve enabled cross-team collaboration, faster delivery of great code, and bringing together Dev, Ops, and Security.

Visual Reviews

GitLab review applications are a fantastic tool to enable stakeholders from Operations to QA to business owners to evaluate and approve application changes before production.

In GitLab 12.0, we make it easy to provide visual feedback directly from the review app. It’s simple and streamlined, no toggling between different tabs and typing your feedback, helping to shorten review cycles and accelerate delivery.

Project Dependency List

Projects typically include dozens of individual components, which can introduce vulnerabilities. Often, security and compliance teams need to be aware of the specific components included in a project.

Now, we're making it easy to view a project's dependencies in a single source of truth.

Limit access based on IP address

Some organizations want to limit access to their repositories based on specific IP addresses.

In GitLab 12.0, you can specifically prohibit traffic from outside IP addresses from accessing your GitLab data.

Join us for an upcoming event

GitLab MVP badge

This month's Most Valuable Person (MVP) is Wolphin

Wolphin’s contribution to GitLab 12.0 adds multiple extends support to GitLab’s CI, making an already powerful primitive even more spectacular.

Thanks so much to Wolphin for the contribution!

Key improvements released in GitLab 12.0

Visual Reviews

GitLab gives users the ability to automatically create review apps for each merge request. This allows anyone to see how the design or UX has been changed.

In GitLab 12.0, we are expanding the ability to discuss those changes by bringing the ability to insert visual review tools directly into the Review App itself. With a small code snippet, users can enable designers, product managers, and other stakeholders to quickly provide feedback on a merge request without leaving the app.

Visual Reviews

Project dependency list

You can now easily access a project’s Dependency List (sometimes referred to as a Bill of Materials or BOM) from the left sidebar menu.

The BOM indicates what components are included in your project, and often is requested by Security teams and Compliance teams. In addition to being able to view the report, you can also export the report to JSON.

Project dependency list

Restrict access by IP address

Compliance-minded organizations may want to prohibit traffic from outside IP addresses from accessing company resources. This is especially helpful for organizations using VPNs, as you’re now able to restrict traffic from outside a specified subnet from accessing a group’s resources in the GitLab UI.

Configurable at the group level on both self-managed and GitLab.com, maintaining tight control over your organization’s most valued code just became easier than ever.

Restrict access by IP address

File syncing to Web Terminal

In GitLab 12.0, changes made in the Web IDE will now be synced to the Web Terminal. User changes made in the Web IDE can now be tested within the Web Terminal before committing them to the project.

This feature also helps to lower the barrier to entry for new contributors as they’ll be able to view, edit, and test without installing local dependencies for a project.

Please note that GitLab.com only supports Interactive Web Terminals through Private Runners.

Git integration for JupyterHub

Deploying JupyterHub via GitLab’s Kubernetes integration provides an easy way to get started with Jupyter notebooks, which can be used to create and share documents that contain live code, visualizations, and even runbooks.

Starting with GitLab 12.0, JupyterLab’s Git extension is automatically provisioned and configured when installing JupyterHub onto your Kubernetes cluster. This integration enables full version control of your notebooks as well as issuance of Git commands within Jupyter. Git commands can be issued via the Git tab on the left panel or via Jupyter’s command line prompt.

Git integration for JupyterHub

Other improvements in GitLab 12.0

Multiple extends support in .gitlab-ci.yml

The extends keyword allows users to keep their GitLab CI/CD code dry. Using extends to condense common sections of code is a frequently used feature for advanced users of GitLab CI/CD, and is used by our own teams to build GitLab as well as our Auto DevOps features.

In GitLab 12.0, we’re very happy to welcome a contribution from Wolphin to improve this feature by allowing users to include multiple extends snippets in a single job and, with multiple extends, you can now achieve streamlined and dry CI configuration.

Thanks Wolphin!

Collapsible job logs

In GitLab 12.0, we’re adding the ability to expand and collapse the log output from GitLab CI/CD jobs. This will allow users to more easily debug certain steps in the job, and provide a great overview of the steps when desired - or a detailed view if you want to see the entire output.

This originally started as a community contribution from Matthias van de Meent. Thank you Matthias for your contribution!

Collapsible job logs

Vulnerability database available for viewing and accepting contributions

Our vulnerability database project can now be viewed here. You can view the entries and verify the vulnerabilities you are most interested are a part of our checks.

In addition, here are guidelines on how you can contribute to help make the vulnerability database more robust.

Lock all memberships to LDAP

Organizations leaning on LDAP typically synchronize it with GitLab for permissions management.

In GitLab 12.0, instances can now prevent permissions changes outside of LDAP by non-admins with an instance-level setting. With this approach, compliance-minded organizations can use this option to ensure that the permissions in LDAP are reflected on the instance - and aren’t modifiable by users who aren’t instance admins.

GitLab Insights

GitLab Insights introduced in GitLab Ultimate 11.9 (feature flag) is now Generally Available (GA) in GitLab Ultimate 12.0.

Configure the Insights that matter for your projects to explore data such as triage hygiene, issues created/closed per a given period, average time for merge requests to be merged and much more.

GitLab Insights

Improved support for passing variables to downstream pipelines

In GitLab 11.8, we introduced the ability to trigger a downstream pipeline from an upstream bridge job. We also introduced basic support for passing variables to the downstream pipeline.

With GitLab 12.0, we support passing current environmental variables to the downstream pipeline as well. This allows users to provide context to the downstream pipeline as well as to the commit, merge request, or other details from the pipeline that triggered it.

Dependency proxy is enabled per-group by default

In GitLab 11.11, we launched the MVC of the dependency proxy, which allows users to download and cache Docker images for faster, more reliable downloads.

In GitLab 12.0, we have enabled the feature by default at the group level.

Dependency proxy is enabled per-group by default

Developers now can delete tags from the Container Registry via API

The Container Registry API allows GitLab users to easily manage their registry programmatically.

With GitLab 12.0, we have updated the permissions model to allow Developers to delete a tag.

Enabled Git bitmap hash cache to speedup repacking

In GitLab 12.0, when repacking Git repositories, a bitmap hash cache will be saved in the bitmap index. The cache improves repack performance, particularly when using delta islands.

Note that versions of JGit prior to 3.5.0 are incompatible with the bitmap hash cache.

Use GitLab Serverless with existing Knative installations

Prior to this release, GitLab Serverless features could only be used when installing Knative via GitLab. With GitLab 12.0, existing installations of Knative can now take advantage of GitLab Serverless. Simply add the existing cluster manually, add the relevant Serverless templates to your project, and GitLab will do the rest.

This means you can now use GitLab Serverless with hosted Knative offerings, such as Google’s Cloud Run on GKE or IBM’s hosted Knative service.

Operations teams often use more complex metrics dashboards for visualizing the state of their environments.

Starting in GitLab 12.0, you can now supply and easily access your external dashboards directly from within GitLab’s environment dashboards.

Link to external dashboards from environment dashboards

Add ability to query epics in GraphQL

GraphQL APIs allows users to request exactly the data they need, making it possible to get all required data in a limited number of requests.

In this release, GitLab is now supporting the ability to query epics in the GraphQL API.

New threaded discussion design

Our existing design for discussions for merge requests and issues involved many boxes and borders, often times making it difficult to follow the conversation.

In GitLab 12.0, we introduced a redesign to enhance the user experience of discussions.

New threaded discussion design

Enhancements for system notes for adding and removing epic relationships

Changes in epic relationships have not been recorded as system notes in the discussion feed of an epic.

In GitLab 12.0, system notes are now recorded for when epic relationships for parent and sub-epics are added or removed.

No longer require Docker in Docker for DAST

Dynamic Application Security Testing (DAST) no longer requires the use of Docker in Docker to run. As a result, the DAST Docker image (3GB) will now be cached on Runners.

Note that the image is updated weekly, so the cache will be invalidated every Monday.

Sequential merge trains

With the 12.0 release we’re introducing a new way to keep your master or release branches green: merge trains. Merge trains build on our pipelines for merge requests/results feature by allowing you to queue up pipelines in sequence.

For this first iteration, it’s important to note that merge train pipelines run in sequence (one at a time) so, depending on the frequency and duration of your pipelines, it may or may not be appropriate to enable this feature yet for your team.

In the future we plan to enable it by default, but we want to have parallelization support in place first to make it more accessible to more teams.

Sequential merge trains

Group-specific notification email addresses

In 12.0, we have added the ability to select a separate email address for group notifications. This now allows users to separate group notifications to different email addresses. For example, a work email address for a work group and a personal email address for personal groups.

Group-specific notification email addresses

Add a reason when dismissing vulnerabilities

When dismissing a vulnerability identified by our scanners, there is now a field available to add a reason detailing why this vulnerability was dismissed.

This will allow security teams and developers to be able to review the history and understand why items were not remediated.

Add a reason when dismissing vulnerabilities

Prevent non-admins from deleting projects

Compliance-minded organizations may wish to ensure that projects - which may include important code in a repository - can only be archived, rather than deleted and permanently lost.

With an instance-level setting to prevent project deletion by non-admins, instance administrators can feel more secure knowing that projects are being archived and retained.

Prevent non-admins from deleting projects

Email notifications for broken master builds

The GitLab Pipeline Emails service integration allows users to create email alerts on build completion and failure to a list of recipients. Previously, users could only subscribe to all build failures.

In GitLab 12.0, we have added the option to only send the failure notification on the default branch for the project (e.g. master).

Thank you to Peter Marko for this contribution!

Email notifications for broken master builds

Faster shallow clones by default for all new projects in GitLab CI/CD

Since GitLab 8.9, GitLab CI/CD has supported shallow git clones by specifying the GIT_DEPTH variable in your job definition.

In GitLab 12.0, we’ve added the ability to set this depth at the project level - enabling project maintainers to default to a shallow clone if desired. Shallow Git clones are faster than cloning the entire Git repository every time, and if your CI/CD jobs are set up to build the latest, often a shallow clone is sufficient.

Also in GitLab 12.0, new projects created in GitLab will, by default, have a GIT_DEPTH setting of 50 when they are created. This sensible default will help users have faster clone and build times with GitLab CI/CD, while still allowing advanced users to change this setting if required for different types of CI/CD use cases.

Maven template now automatically pushes to the Maven Repository

Java developers need an easy way to build and manage their dependencies with GitLab’s CI/CD pipelines.

In GitLab 12.0, we have modified the bundled Maven.gitlab-ci.yml template to easily allow users to upload and manage their Java dependencies to the GitLab Maven Repository from their CI/CD pipelines.

Git object deduplication (Beta)

Forking workflows make it easy to contribute to any project by creating a copy of the upstream project to work on before opening a merge request to merge your changes into the upstream project. For popular projects, the server side storage requirements needed for thousands of copies accumulate quickly and increase hosting costs.

In GitLab 12.0, object deduplication can be enabled by instance administrators using the object_pools feature flag. When enabled, creating a fork of a public will also create an object pool and use objects/info/alternates to reduce the storage requirements of forks.

Object deduplication requires hashed storage to be enabled, and for the parent project to be using hashed storage. Existing forks are not currently migrated to object pools automatically – for updates follow gitaly#1560.

In an upcoming release, we will also implement fast forking by directly creating the fork in a deduplicated state. Currently the fork is first created, then deduplicated.

Object deduplication has been enabled on GitLab.com since 30 May 2019, but it remains off by default for self-managed instances because of a duplicate bitmap warning shown when fetching. This issue is fixed in 12.0 but the feature flag could not be removed in time for this release.

Validate Kubernetes credentials provided at cluster creation

Adding a Kubernetes cluster manually requires entering multiple data points and can be error prone. In order to effectively surface access and permission issues when adding a cluster manually, the kubernetes integration will now validate the reachability of the API URL as well as the validity of both then cluster token and CA certificate.

Relevant alerts will be presented when an issue is encountered.

Validate Kubernetes credentials provided at cluster creation

In GitLab 12.0, we have made it easy to collaborate with teammates on an issue via a Zoom conference call. Paste a Zoom meeting link in the description of an issue. GitLab will detect the link and display a “Join Zoom meeting” button at the top underneath the title surfacing it to all collaborators.

Link and access a Zoom meeting from an issue

Notifications for shared CI runner limits on GitLab.com

Group owners on GitLab.com will now be notified via email to let them know that the group’s CI Minutes Usage Quota has expired, with instructions on how to purchase more CI Minutes.

Issue API now responds with task completion statistics

Users are able to define tasks in issues and this information is surfaced in various places throughout the application.

In GitLab 12.0, users will now have the ability to return task progress information through the API.

Additional issue stats from the issues API

Users have been unable to get detailed issue statistics from the issues API.

In GitLab 12.0, we are adding the ability to return counts of issues for all, closed, and opened states.

Add and remove child epics via quick actions

Child epics cannot currently be added or removed from parent epics via quick actions.

In GitLab 12.0, we have added the ability to add and remove child epics via the /child_epic and /remove_child_epic quick action commands.

Support for AsciiDoc include directive

The AsciiDoc markup format supports declaratively including content from other files, allowing unnecessary duplication to be removed from documents. The AsciiDoctor implementation presumes a local file system, not a Git repository, preventing includes from being rendered when viewing an AsciiDoc file inside GitLab.

In GitLab 12.0, the include directive (include::example.adoc[]) is now supported, allowing text files in the same branch or tag to be included when viewed in GitLab.

Thanks Guillaume Grossetie for your contribution!

Omnibus improvements

We continue to improve the GitLab Omnibus with every release.

Some of the improvements in GitLab 12.0 are:


GitLab 9.x now out of support scope

As we introduce a new major version of GitLab, GitLab 9.x now falls outside of our scope of support. We invite customers to upgrade to at least GitLab 10.0 to benefit from our Support team’s assistance.

Planned removal date: Jun. 22, 2019

GitLab Geo requires Hashed Storage in GitLab 12.0

With GitLab 12.0, GitLab Geo requires Hashed Storage to mitigate race conditions on secondary nodes. Please use sudo gitlab-rake gitlab:geo:check to see if Hashed Storage is enabled and all projects are migrated. See the documentation on how to migrate to Hashed Storage.

This was also noted in previously.

In GitLab 11.5, we added this requirement to the Geo documentation.

With GitLab 11.6, sudo gitlab-rake gitlab:geo:check checks that Hashed Storage is enabled and all projects are migrated. If you are using Geo, please run this check and migrate as soon as possible.

In GitLab 11.8, a permanently dismissable warning is displayed on the Admin Area › Geo › Nodes page if the above checks are not resolved.

Planned removal date: Jun. 22, 2019

GitLab Geo requires PostgreSQL Foreign Data Wrapper in GitLab 12.0

In GitLab 12.0, Geo requires PostgreSQL Foreign Data Wrapper, raising the minimum PostgreSQL version to 9.6. GitLab Geo uses PostgreSQL Foreign Data Wrapper to query data from different PostgreSQL instances. This is needed for Geo Log Cursor, as this significantly improves the performance of some synchronization operations. Foreign Data Wrapper also improves the performance of the Geo node status queries. For large projects, the legacy queries had unacceptable performance.

See how to set PostgreSQL Foreign Data Wrapper up in the Geo database replication documentation.

Planned removal date: Jun. 22, 2019

Remove use of app as matching mechanism for Kubernetes deploy boards

In GitLab 12.1, we will remove the app label matching for the Kubernetes deployment selector (removal was originally scheduled for 12.0). As part of GitLab 11.10, we introduced a new matching mechanism which uses app.gitlab.com/app and app.gitlab.com/env to show deployments on deploy boards.

In order to see these deployments in your deploy boards, all you need to do is push a new deployment and GitLab will use the new labels for your deployments.

Planned removal date: Jun. 22, 2019

Removal of AUTO_DEVOPS_DOMAIN environment variable

The new KUBE_INGRESS_BASE_DOMAIN environment variable was introduced as part of GitLab 11.8. It is no longer necessary to use AUTO_DEVOPS_DOMAIN to define multiple domains as these can now be defined individually on the cluster page.

Planned removal date: Jun. 22, 2019

Remove Kubernetes service template

In GitLab 12.1, we plan to remove the instance-level Kubernetes service template in favor of the instance-level cluster functionality introduced in GitLab 11.11.

Any self-managed instance making use of the service template will be migrated to an instance-level cluster as part of upgrading to GitLab 12.0.

Planned removal date: Jun. 22, 2019

Remove support for skip_auto_migrations file

In GitLab 12.0, we are completely removing support for skip_auto_migrations file. This was previously deprecated in GitLab 10.6.

Planned removal date: Jun. 22, 2019

Remove Prometheus 1.x support

In GitLab 12.0, we are completely removing support for Prometheus 1.x.

Planned removal date: Jun. 22, 2019

Deprecation of openSUSE 42.3

openSUSE 42.3 reaches end of life on June 30, 2019. We will continue to build packages for it until GitLab 12.1, with plans to drop support in GitLab 12.2.

Planned removal date: Jun. 22, 2019

Deprecate legacy code paths in GitLab Runner

Since GitLab 11.9, GitLab Runner has been using a new method for cloning/fetching the repository. Currently, GitLab Runner will use the old method if the new one is not supported. Please see this issue for additional details.

In GitLab 11.0, we changed how the metrics server is configured for GitLab Runner. metrics_server has been removed in favor of listen_address in GitLab 12.0. Please see this issue for additional details.

In 11.3, GitLab Runner started supporting multiple cache providers. This resulted in new settings for S3-specific configuration. In the documentation, there is a table of what changed, and how to migrate to the new configuration. Please see this issue for additional details.

These paths are no longer available in GitLab 12.0. As a user, you don’t have to change anything apart from making sure the GitLab instance is running 11.9+ when upgrading to GitLab Runner 12.0.

Planned removal date: Jun. 22, 2019

Deprecate entrypoint feature flag for GitLab Runner

In GitLab 11.4, GitLab Runner introduced a feature flag FF_K8S_USE_ENTRYPOINT_OVER_COMMAND in order to fix issues like #2338 and #3536.

In GitLab 12.0, we switch to the correct behavior as if the feature flag was turned off. Please see this issue for additional details.

Planned removal date: Jun. 22, 2019

Deprecate support of Linux distributions that reached EOL for GitLab Runner

Some Linux distributions in which you could install GitLab Runner have reached End of Life support.

In GitLab 12.0, GitLab Runner no longer distributes packages to those Linux distributions. A full list of distributions that are no longer supported can be found in our documentation.

Thanks Javier Jardón for your contribution!

Planned removal date: Jun. 22, 2019

Remove legacy GitLab Runner helper commands

As part of adding support for Windows Docker executor, we had to deprecate some old commands that are used for the helper image.

In GitLab 12.0, GitLab Runner starts using the new commands. This only affects users who are overriding the helper image. Please see this issue for additional details.

Planned removal date: Jun. 22, 2019

Remove legacy Git clean mechanism from GitLab Runner

With GitLab Runner 11.10, we introduced a way to configure how git clean command is being executed by Runner. Additionally, the new cleanup strategy removes the usage of git reset and moves the git clean command after the checkout step.

In GitLab Runner 12.0, GitLab Runner drops support for the legacy cleanup strategy and removes the ability to restore it with a feature flag. Please see this issue

Planned removal date: Jun. 22, 2019

Secure License Management renamed to License Compliance in GitLab 12.0

License Management is being renamed to better align with common industry vernacular starting in GitLab 12.0. The purpose of License Compliance is to analyze your application to track which licenses are used by third-party components, like libraries and external dependencies, and check that they are compatible with your project’s licensing model.

License Compliance is part of our Secure Composition Analysis group.

Planned removal date: Jun. 22, 2019

Deprecated variables and argument for manual configurations of .gitlab-ci.yml when using Secure features

If you have manually configured your .gitlab-ci.yml configuration file to use the:

  • Command line argument --auth-first-page, you need to remove this argument as it is no longer supported.
  • DEP_SCAN_DISABLE_REMOTE_CHECKS flag variable, you need to remove this as it is no longer supported.
  • sast_container value in GITLAB_FEATURES environment variable, you must change to use container_scanning instead.

If you have manually configured your .gitlab-ci.yml configuration file, verify that you are using the new report syntax. All Secure features are dependant on the reports being available in the expected location. If you do not update to the new report syntax, all Secure features will stop working.

If you utilize vendored templates instead of manual configuration, your configuration will be kept up to date with variable and argument changes.

Planned removal date: Jun. 22, 2019

No maintained manual Secure configuration snippet from GitLab 12.0

We will no longer update the Secure manual configuration snippet in the documentation that is utilized when you are configuring Secure features in your project pipeline.

Please use vendored template inclusion for Secure in your .gitlab-ci.yml configuration by using include: template: Dependency-Scanning.gitlab-ci.yml.

Planned removal date: Jun. 22, 2019

3DES is now disabled on GitLab.com Pages by default

GitLab.com Pages previously allowed 3DES, which is being deprecated.

To mitigate this, going forward 3DES will be disabled by default. This should not change anything for users of modern browsers, but some users of Internet Explorer versions 7 and 8 running on the Windows XP operating system may be impacted.

Planned removal date: Jun. 22, 2019

Remove support for MySQL in GitLab 12.1

GitLab 12.0 is the last version with support for MySQL (and MariaDB). Users will need to migrate to PostgreSQL in order to utilize future versions. MySQL has been considered deprecated and support for it was previously limited to Enterprise Edition Starter and Premium.

If you are a GitLab customer using MySQL, please contact our customer support team for assistance with the migration.

Planned removal date: Jul. 22, 2019

Sentry settings for error reporting and logging will be removed from the UI in GitLab 12.1

These settings will be removed from the UI in GitLab 12.1 and have been made available within gitlab.yml in GitLab 11.11. In addition, you will be able to define a Sentry Environment to differentiate between multiple deployments like development, staging, and production. See gitlab-ce#49771 for more details.

Planned removal date: Jul. 22, 2019

Group project templates fixed to Silver/Premium tier

When we introduced group-level project templates in GitLab 11.6, we unintentionally made this Premium/Silver feature available at any tier.

We fixed this bug in GitLab 11.11 by giving any existing users/instances lower than Silver/Premium a grace period of three months.

On August 22nd, 2019, this grace period will expire and group project templates will require Silver/Premium or higher as documented.

Planned removal date: Aug. 22, 2019

License Management will use Python 3 as the default in GitLab 12.2

Python 3 will become the default version used by the Secure stage License Management.

Users with Python 2 will need to set the CI variable LM_PYTHON_VERSION to “2” if they are self-managed when they start using GitLab 12.2. Users with Python 3 can change the CI variable LM_PYTHON_VERSION to “3” today.

Planned removal date: Aug. 22nd, 2019

Deprecate support for Windows batch

In GitLab 12.3, we plan to deprecate support for Windows batch command line jobs in the GitLab Runner (e.g. cmd.exe) in favor of extended and expanding support for Windows PowerShell.

This will align our vision for enterprise DevOps with Microsoft’s position that PowerShell is the right technology to automate enterprise applications in Windows-based environments.

For users that may still want to run items against cmd.exe, those commands can be invoked from PowerShell, but we will not provide direct support for Windows batch as there are a number of inconsistencies in batch which results in a high cost for maintainability and development.

Planned removal date: Sep. 22, 2019

Deprecation of job directory caching in GitLab Runner with Docker executor

With GitLab Runner 11.10, we’ve changed what part of the job directory is cached in a shared volume when Docker and Docker Machine executors are used. Instead of caching only the parent directory of the job working directory, GitLab Runner is now caching the whole base directory configured with builds_dir. Because it is a behavior change, we’ve added a feature flag that allows to control whether the new or old behavior should be used.

With GitLab Runner 12.3, we will remove the feature flag and the old behavior. Please see this issue.

Planned removal date: Sep. 22, 2019

Python 2 support in Secure License Management will be deprecated by end of the year

Support for Python 2 would be dropped in a future GitLab release due to Python 2.7 reaching the end of its life on January 1st, 2020.

Planned removal date: Dec. 22nd, 2019

Removals and breaking changes

The complete list of all removed features can be viewed in the GitLab documentation.

Important notes on upgrading to GitLab 12.0

  • GitLab 12.0 merges the database changes made by Enterprise Edition over the years into Community Edition. As part of this work, we have also removed various old migrations. Users upgrading to their GitLab installation must first upgrade to the latest 11.11 patch release, then upgrade to 12.0.0. When upgrading to a future version such as 12.3.0, users must first upgrade to the latest 11.11 patch release as per our recommended upgrade paths. Failing to do so may result in migrations not being applied, which could lead to application errors. Omnibus installations already enforce upgrading to 12.0.0, and GitLab Helm Chart enforces a similar upgrade path. Installations from source will have to take care of this manually.
  • GitLab 12.0 will use Hashed Storage by default. This only affects new installations.
  • GitLab 12.0 will automatically upgrade the PostgreSQL version to 10.7.
    • Users have the ability to skip the auto upgrade of PostgreSQL 10.7 creating /etc/gitlab/disable-postgresql-upgrade.
    • If you use GitLab Geo, the automatic PostgreSQL upgrade will be skipped on both the primary and all secondary nodes. We will provide an upgrade path for Geo users in 12.1.
  • GitLab 12.0 will enable JSON logging by default. We have also added documentation on how to retain previous log format settings where JSON is not desired.
  • Further information related to important Omnibus upgrade information in the documentation.


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


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


Check out our update page.


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

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