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

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

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

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.

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.

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.

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

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.

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

Join us for an upcoming event

Thanks so much to Wolphin for the contribution!

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

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

Some of the improvements in GitLab 12.0 are:

We continue to improve the GitLab Omnibus with every release.

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.

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, we have added the ability to add and remove child epics via the /child_epic and /remove_child_epic quick action commands.

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

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

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

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

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

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.

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.

Relevant alerts will be presented when an issue is encountered.

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.

Object deduplication has been enabled on GitLab.com since 30 May 2019, but it remains off by default for self-hosted 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.

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

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

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

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.

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.

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

Thank you to Peter Marko for this contribution!

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

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.

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.

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.

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

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

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.

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.

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.

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.

Some of the improvements in GitLab 12.0 are:

We continue to improve the performance of GitLab with every release for GitLab instances of every size.

A list of all changes can be found in GitLab Runner’s CHANGELOG .

As mentioned in previous posts, with version GitLab Runner 12.0, we’re also removing a few previously deprecated things:

We’re also releasing GitLab Runner 12.0 today! GitLab Runner is the open source project that is used to run your CI/CD jobs and send the results back to GitLab.

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

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.

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

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

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

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 this release, GitLab is now supporting the ability to query epics in the GraphQL API.

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.

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

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

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 .

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.

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

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.

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

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

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

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.

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.

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.

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 introduced in GitLab Ultimate 11.9 (feature flag) is now Generally Available (GA) in GitLab Ultimate 12.0.

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.

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

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

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.

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

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.

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.

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.

Deprecations

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.

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

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

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

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

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

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

Deprecation date: Jun. 22, 2019

Remove Prometheus 1.x support

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

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

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

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

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

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

Deprecation 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

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

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

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

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.

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

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

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

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

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

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

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

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

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

Deprecation date: Dec. 22nd, 2019