is moving to 13.0, with narrow breaking changes

May 6, 2020 · 7 min read
Joshua Lambert GitLab profile

GitLab 13.0 is coming on May 22, 2020 to Along with the exciting new features, it also includes planned deprecations because it is this year's major version release. We try to minimize these changes, but some are important enough to warrant the change in functionality.

These changes will be going live on over the next few days, through our daily deployments, leading up to the official release of 13.0 on May 22nd. Keep reading to learn more about these important changes.

Auto DevOps default PostgreSQL chart version changing to 8.2.1

As part of updating Auto DevOps to support Kubernetes 1.16, the default PostgreSQL chart version is changing from 0.7.1 to 8.2.1.

To migrate your existing 0.7.1 PostgreSQL database to the newer 8.2.1-based database, follow the upgrade guide to backup your database, install the new version of PostgreSQL, and restore your database.

To remain on the old default, you will need to explicitly set the AUTO_DEVOPS_POSTGRES_CHANNEL CI variable to 1.

Auto DevOps Auto Deploy default setting for deploymentApiVersion changing

Because several APIs were removed in Kubernetes 1.16, the deploymentApiVersion setting is changing to a new default of apps/v1 in GitLab 13.0

If you are using Kubernetes 1.9 and below, you will need to upgrade your Kubernetes cluster to get apps/v1 version support. For Auto DevOps, GitLab requires Kubernetes 1.12+.

Auto DevOps and Secure Configuration templates are changing to rules instead of only/except

The use of only and except is discouraged in favor of rules. rules provides more verbose and expressive job execution  logic that is less complex to evaluate and understand. 

Auto DevOps and Secure configuration templates that use only and except are changing to rules. Users who have customized job templates will need to transition as these two configuration options cannot be used together. We have documentation available for help migrating your templates.

This change will affect the following job configuration templates: 

Any customization to these templates using only and except must be changed to the rules syntax. only/except can’t be used in combination with rules since it’s intended to be replaced by that functionality. Please see our troubleshooting doc for guidance on transition your rules or pinning to the previous version.

We would love to hear more about these cases in this rules improvement issue.

Relevant issues: 

Offset pagination limit of 50,000 for /projects endpoint

An offset-based pagination limit of 50,000 is being applied to the /projects API endpoint on Integrations that make API calls with offsets above 50,000 must switch to keyset-based pagination, which will offer significantly improved response times and reduced load on the GitLab server. Self-managed instances can customize the limit to a desired value.

To optimize performance, keyset-based pagination only offers ordering based on project id. Use cases that require more flexible ordering options can continue to use offset-based pagination, provided the offsets remain below the limit. If use cases require flexible ordering options with deep offsets, we recommend sorting client-side.

As we continue to work towards version control for Snippets, we are making a change to search for Snippets in the UI and API that removes snippet Content from search results. Title and Description will still be accessible via search and API.

Introducing a new id field which replaces the deprecated cve field in the JSON common security report

As we add (and encourage third-party vendors to add) more security integrations, we're working to improve our current JSON common report format. The primary field cve property is confusing, as it does not contain CVE data and should therefore be removed. We are introducing the id field, which is automatically calculated for GitLab scanners and required for third-party partner scanners. The id field will eventually replace cve as a unique identifier. Anyone leveraging the cve property in security reports, with custom scripts or as an integrator into our Secure features, will eventually need to stop using the cve property and instead should start using the new id property. Please be aware that today id and cve are both required fields.

Removal of token attribute in Runner's details API

We are removing the token attribute from the Runners API endpoint that gets details of a Runner by its ID. You can provide feedback in the related issue or your usual support channels.

Removal of deprecated project paths

With the introduction of subgroups, GitLab's URL path structure became more complex. We've been introducing a separator, /-/, to improve clarity between groups, projects, and pages within a project. For example, is now These changes result in improved performance, stability, and simplicity.

As we introduce the separator to additional pages, we automatically redirect requests to the old paths to the new ones. With GitLab 13.0, we are removing this redirect for pages which have had the separator since GitLab 12.0.

Regular usage of GitLab will not be impacted by this change. However bookmarks or scripting created over a year ago, utilizing an affected path, will need to be updated to utilize the new path.

GitLab Runner 13.0 breaking changes

To utilize License Compliance you must use the new License Scanning template

As of GitLab 13.0 for self-managed, and this week for users, we have removed the template (deprecated since GitLab 12.8). You must replace it with the License-Scanning.gitlab-ci.yml template instead. For more details visit the documentation.

If you are directly referencing the results of the License Scan running as part of License Compliance, you also need to use the new report type artifacts:reports:license_scanning instead of artifacts:reports:license_management. This is optional with the release of GitLab 12.8 through GitLab 12.10, but mandatory with the release of GitLab 13.0. This will not apply to users of versions GitLab 12.7 and earlier.

This change was made because GitLab License Management is now renamed to GitLab License Compliance. After review with users and analysts, we determined that this new name better indicates what the feature is for, aligns with existing market terminology, and reduces confusion with GitLab subscription licensing features. You can find the research and work on this issue in the epic Rename License Management to License Compliance. The analyses of your projects done as a part of License Compliance will be called License Scanning.

“ is moving to 13.0, including narrow breaking changes. Find out how this could affect you and if so what to do.” – Joshua Lambert

Click to tweet

Master your CI/CD

Watch this webcast and learn to deliver faster with CI/CD.

View now
Edit this page View source