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
Auto DevOps Auto Deploy default setting for
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
Auto DevOps and Secure configuration templates
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:
- Secure vendored
Any customization to these templates using
except must be changed to
only/except can’t be used in
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.
An offset-based pagination limit of
50,000 is being applied to the
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
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
Removing GitLab Snippets content from search
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.
marked_for_deletion_at attribute in Projects API
For customers using GitLab Silver, Premium, or above, GitLab's API response when
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
shared_projects attributes from the response when requesting
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
will eventually replace
cve as a unique identifier. Anyone leveraging the
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
cve are both required fields.
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
cmdfor 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
- debug/jobs/list?v=1 endpoint: In 13.0, the
/debug/jobs/list?v=1endpoint used for monitoring is replaced with the
- Docker services flag on register command: In GitLab Runner 12.7 we introduced the ability to allow a service alias from
configin the Docker executor. In 13.0, the old structure,
--docker-serviceswill also be removed. This means that the following option
gitlab-runner register --docker-services postgreswill no longer set the service as the configuration is no longer an array of strings. For users with automation that relies on the
--docker-servicesflag, 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.