GitLab.com is moving to 13.0, with narrow breaking changes


GitLab 13.0 is coming on May 22, 2020 to GitLab.com. 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.

Keep reading to learn more about these important changes to GitLab.com, which will be arriving over the next few days leading up to release on May 22.

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: 

  • Build.gitlab-ci.yml
  • Test.gitlab-ci.yml
  • Deploy.gitlab-ci.yml
  • Secure vendored .gitlab-ci.yml templates
    • Container-scanning.gitlab-ci.yml
    • DAST.gitlab-ci.yml
    • Dependency-Scanning.gitlab-ci.yml
    • License-Management.gitlab-ci.yml
    • License-Scanning.gitlab-ci.yml
    • SAST.gitlab-ci.yml

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: 

An offset-based pagination limit of 50,000 is being applied to the /projects API endpoint on GitLab.com. 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.

Removal of marked_for_deletion_at attribute in Projects API

For customers using GitLab Silver, Premium, or above, GitLab's API response when listing projects currently returns an attribute named marked_for_deletion_at that denotes the date on which a project was marked for soft deletion.

To standardize on terminology across our APIs, this attribute is removed in GitLab 13.0. A new attribute named marked_for_deletion_on with the same information has  already been added.

To improve performance, in GitLab 12.9 we limited the number of projects returned from the groups/:id endpoint in the group details API to 100.

To further improve endpoint performance, in GitLab 13.0 we are removing the projects and shared_projects attributes from the response when requesting group details through the API. Users can still find this information in the same Group API, in the list a group's projects endpoint.

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.

GitLab Runner 13.0 breaking changes

  • Windows Batch cmd for the shell executor: In GitLab 11.11, we deprecated the use of Windows Batch executor for the GitLab Runner in favor of PowerShell. In 13.0 we will remove support for Windows batch (cmd) from the Runner shell executor. When a user registers a new runner shell executor it will now default to powershell.
  • debug/jobs/list?v=1 endpoint: In 13.0, the /debug/jobs/list?v=1 endpoint used for monitoring is replaced with the /debug/jobs/list?v=2 endpoint.
  • Docker services flag on register command: In GitLab Runner 12.7 we introduced the ability to allow a service alias from config in the Docker executor. In 13.0, the old structure, --docker-services will also be removed. This means that the following option gitlab-runner register --docker-services postgres will no longer set the service as the configuration is no longer an array of strings. For users with automation that relies on the --docker-services flag, click here for a migration example.
  • Legacy build directory caching feature flag: In GitLab Runner 13.0 we will remove the legacy build directory caching feature flag that was introduced in 11.10. We highly recommend that users do not store anything in the Builds Directory. Refer to the Build Directory section of the best practices documentation page for additional details.
  • Windows 1803 support end of life: In GitLab Runner 13.0, Windows 1803 is no longer supported.
  • Fedora 29 support end of life: In GitLab Runner 13.0, Fedora 29 is no longer supported.

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

As of GitLab 13.0 for self-hosted, and this week for GitLab.com users, we have removed the License-Management.gitlab.ci.yml 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.