Progress since GitLab 12.0
At this milestone release of 13.0, we’d like to take a moment to reflect. We’ve accomplished so much since our 12.0 release! We've put together a blog to recap GitLab 12.0 to 12.10. Three favorites from version 12 releases include: Requirements Management, Container Network Security, and Parent-child pipelines. In addition to product enhancements, we've embraced partnerships/integrations, adding integration guidelines for third-party security scanners, and have grown our professional services to help you with things like Jira and Jenkins migrations. Our new channel, Learn@GitLab makes it easy to find many new how-to videos such as Getting started with CI.
Iteration is the key to resilience
GitLab is enabling IT and business teams to adapt, respond, and thrive. Iteration is the key. To do so you must collaborate rapidly, optimize for efficiency, and automate processes to handle security and compliance while you focus on delivering business value. GitLab 13.0 can help you iterate quickly and with greater insight. At the same time, access to Git repositories is critical, and we have enhanced our Gitaly cluster for high availability Git storage to ensure there are always multiple warm replicas ready to take over if an outage occurs.
Rapidly collaborate and respond across the entire team
GitLab builds upon capabilities that help with collaborative development, reporting, organizing, and managing work. Version control is foundational to collaboration and, with 13.0, we have added version control for snippets. To manage more complex projects, 13.0 allows you to view the epic hierarchy on your roadmap, view how your epics line up with your various milestones, and add a single or multiple milestones to your releases while alerts upon closing an issue with open blockers help you focus on critical path items.
Designers are an important part of the development team. While working on one of the most popular new features, the dark themed web IDE, we learned how to pull designers in to collaborate more closely. At the same time, we moved Design Management to core recognizing users who are designing products as individual contributors.
Optimize for efficiency
As many businesses strive to be more responsive and efficient, GitLab helps streamline existing software development processes. New features aimed at efficiency include things like simplified deployment to Amazon ECS and a new consolidated list of alerts that provides a single interface aggregating IT alerts originating from multiple sources. In addition, Terraform users will rejoice. GitLab 13.0 lets you review the summary of terraform plan
in Merge Requests and use GitLab as an HTTP Terraform state backend.
Trust your processes and don’t sacrifice security or compliance
GitLab helps businesses embrace security and compliance controls end-to-end in the software development lifecycle, reducing risk and freeing up resources to focus on business critical needs. Our Application Security Testing capabilities help you find and fix security vulnerabilities earlier and for these, GitLab was just named as a Niche Player in the 2020 Gartner Magic Quadrant for Application Security Testing. Since Gartner's evaluation of 12.4, we have added many new features. In 13.0 alone we've added the ability to scan REST APIs via DAST and a full commit history scan for secrets for even greater detection. More importantly, we have rearchitected the way we handle vulnerability objects. This enabled the ability to export vulnerabilities from the security dashboard and will unlock many more robust Vulnerability Management capabilities in the future.
In addition to security scanning, GitLab automates policies and, with 13.0, provides more granular control with new features such as setting a deployment freeze with the Freeze Period API to easily prevent an unintended production release during a specified period of time. To simplify audits, you can now filter search for instance-level audit events as part of a the larger epic.
Looking ahead
We are excited about our upcoming releases, particularly features that will help you:
Want to see the complete list of what’s coming out NEXT month? Our roadmap is transparent and always available for you to contribute!
Now, without further ado, check out more fabulous updates in 13.0 below!
Gitaly Cluster for high availability Git storage
GitLab now supports highly available Git storage without using NFS. High Availability (HA) configurations improve the availability of important systems, like Git storage, by removing single points of failure, detecting outages, and automatically switching to a replica. This means that an individual component of the system can fail without causing the end user to experience an outage. Access to Git repositories is critical to developers and businesses, because when an outage occurs, developers can’t push code, and deployments are blocked.
Internally, Git repository storage is handled by Gitaly, and now Praefect too. Praefect is a new router and transaction manager we built for Gitaly to coordinate leader election and asynchronous replication. When using a Gitaly Cluster, requests for Git data are routed through one of multiple Praefect nodes to a Gitaly node. This means that there are always multiple warm replicas ready to take over if an outage occurs.
In the future we plan to support strong consistency, so that write operations succeed on multiple Gitaly nodes, before responding with a success signal, and support horizontally distributing reads so that CPU and memory resources can be better scaled.
Deprecations
Auto DevOps Auto Deploy setting value deprecated
Because several APIs were removed in Kubernetes 1.16, the default value of extensions/v1beta1
for the deploymentApiVersion
setting in Auto DevOps’ Auto-Deploy chart is now deprecated in GitLab 13.0.
In GitLab 13.0, the deploymentApiVersion
setting changes to a new default of apps/v1
. If you are using Kubernetes 1.9 and below, you must upgrade your Kubernetes cluster to support apps/v1
. For Auto DevOps, GitLab requires Kubernetes 1.12+.
Deprecation date:
May. 22, 2020
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
in Auto DevOps and Secure Configuration templates. The rules
parameter provides more verbose and expressive job execution logic that is simpler to evaluate and easier to understand.
Auto DevOps and Secure configuration templates that use only
and except
will transition to rules
, starting in GitLab 13.0. We strongly encourage customers who have customized job templates to transition because the only/except
and rules
syntax cannot be used together. For help migrating your templates, see Transition your only/except
syntax to rules
.
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 Auto DevOps and Secure Configuration templates using only
and except
should be transitioned to the rules
syntax. There are occasional cases where the existing only
and except
syntax cannot be easily matched with rules
. We would love to hear more about these cases on this rules
improvement issue.
Relevant issues:
Deprecation date:
May 22, 2020
Auto DevOps' default PostgreSQL version is changing
As part of updating Auto DevOps in GitLab 12.9 to support
Kubernetes 1.16, we added the opt-in ability for Auto DevOps to use the
PostgreSQL chart version 8.2.1. The default PostgreSQL chart version in
GitLab 12.10 is currently 0.7.1. GitLab 13.0 switches the default
PostgreSQL chart version from 0.7.1 to 8.2.1. To remain on the old
default version, you must explicitly set the
AUTO_DEVOPS_POSTGRES_CHANNEL
CI variable to 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.
Deprecation date:
May 22, 2020
Deprecate Windows batch `cmd` for the shell executor
In GitLab 11.11, we announced the deprecation of the Windows batch executor, Cmd shell, for the GitLab Runner in favor of PowerShell. In 13.0, we have deprecated the use of the Windows batch executor for the GitLab Runner. PowerShell is the default command shell when a new Runner is registered that uses the Windows executor starting with GitLab Runner 12.0. The Cmd shell remains included in future versions of GitLab Runner. However, any new Runner feature is to be tested and supported only for use with PowerShell. You can find more details in issue #4163.
Deprecation date:
May 22, 2020
Deprecation of Docker-in-Docker (DinD) for Security Scanners
To increase the security and reduce complexity of scans, use of Docker-in-Docker (DinD) in GitLab Secure scanners has been deprecated. GitLab security products will begin to use non-DinD mode by default in vendored templates in GitLab 13.0. We encourage customers to update their vendored templates to use this new behavior.
If you want to continue using DinD mode instead, see Enabling Docker-in-Docker for Dependency Scanning. In a future release we intend to remove DinD completely. Please be aware of slight changes in scanner detection logic, which we have largely mitigated.
Deprecation date:
May 22, 2020
GitLab Pages `auth-server` to be removed in 14.0
We’re changing how some of the configuration options in GitLab Pages behave to streamline the initial setup, while helping you avoid misconfiguration. If you installed GitLab by using the Omnibus, no action is required. Otherwise, you’ll need to set the gitlab-server
parameter and remove auth-server
.
Deprecation date:
May 22, 2021
Planned deprecation of variables SAST_ANALYZER_IMAGE_PREFIX and DS_ANALYZER_IMAGE_PREFIX in Secure CI Templates
To help streamline and simplify the setup of GitLab Security Tools, we have introduced a new global variable SECURE_ANALYZERS_PREFIX
which by default points at the GitLab registry. This variable replaces the now deprecated variables in SAST and Dependency scanning: SAST_ANALYZER_IMAGE_PREFIX
and DS_ANALYZER_IMAGE_PREFIX
. Support for these deprecated variables will be removed in a future release, so please migrate any usage to SECURE_ANALYZERS_PREFIX
.
You can override this variable to easily affect all security scanners at once. This is useful in situations where you are using your own registry images which is common in offline and air-gapped environments.
Related Links:
Deprecation date:
June 22, 2020
Planned removal of legacy storage in 14.0
GitLab currently supports two types of storage for repositories: Legacy storage and hashed storage. Hashed storage makes the folder structure immutable and results in performance and security improvements.
Hashed storage has been available since GitLab 10.0 and is on by default since GitLab 12.0. GitLab.com has been fully migrated to hashed storage. With GitLab 13.0 legacy storage is deprecated and we are planning to fully remove legacy storage in 14.0.
In 13.0:
- Legacy storage is deprecated and usage is strongly discouraged. Please follow instructions on how to migrate fully to hashed storage.
- Administrators will no longer be able to disable hashed storage for new projects.
- New projects and renamed projects will use hashed storage by default.
- When renaming or moving projects they will be migrated to hashed storage automatically.
In 13.2:
- Upon upgrading to 13.2, all projects still in legacy storage will be automatically migrated via a background migration.
- Some new features may require hashed storage and won’t be available when using legacy storage.
In 14.0:
- Legacy storage support will be completely removed from GitLab. Users must migrate to hashed storage before upgrading to 14.0.
Deprecation date:
May 22, 2020
Prometheus replaces InfluxDB for self-monitoring
Starting in GitLab 13.0, InfluxDB is being deprecated in favor of Prometheus for GitLab self-monitoring metrics. Please update your configuration for GitLab reporting and visualizations to use Prometheus, which is installed by default on every GitLab instance.
Deprecation date:
June 22, 2020
Removal of authorized_keys authorization for SSH
The authorized_keys
authorization mechanism for SSH is not scalable, and is vulnerable
to race conditions and out-of-order execution issues. It also requires
a shared filesystem for most deployments of more than one machine.
Fast lookup of authorized SSH keys
solves these issues and is the recommended authorization mechanism. As such,
we are planning to make it the default mechanism starting in GitLab 14.0.
As we work to make fast SSH lookups the default Git+SSH authorization mechanism
in GitLab, we are deprecating the authorized_keys
mechanism, which is currently the default. We plan to make this new mechanism
work out of the box, so there is no impact or action required from GitLab users nor administrators.
Deprecation date:
May 22, 2021
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, https://gitlab.com/gitlab-org/gitlab/issues
is now https://gitlab.com/gitlab-org/gitlab/-/issues
. 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.
Deprecation date:
Jun 22, 2020
Removal of logs view from the admin dashboard
Logs can no longer be viewed from within GitLab admin dashboard. These logs
used to be read directly from disk to be displayed in the admin
interface. Sadly, this does not work in multi-node setups and
could cause confusion for administrators by displaying partial
information. The logs are still available to administrators with
access to the host, please see [the documentation on our log
system for more information. For multi-node systems we recommend ingesting
the logs into services like Elasticsearch and Splunk.
Deprecation date:
May 22, 2020
SSH `authorized_keys` file deprecated
As of GitLab 13.0, the bin/authorized_keys
file used for SSH authorization is deprecated,
replaced by bin/gitlab-shell-authorized-keys-check
, which conducts the authorization through
fast lookup instead.
The deprecated method wasn’t reliable as it doesn’t check that the requesting user matches
the expected user. The final removal is scheduled for GitLab 13.1, released next month (June 22nd, 2020).
Deprecation date:
May 22, 2020
The default method of invoking Sidekiq will be `sidekiq-cluster`
As stated in the 12.10 release post, in GitLab 13.0 we have deprecated alternative
ways of starting Sidekiq in favor of Sidekiq Cluster. Sidekiq Cluster provides additional options for managing Sidekiq queues and scaling.
This enables running multiple Sidekiq processes for Core instances (a previously EE exclusive feature). Multiple Sidekiq processes allow a GitLab instance to continue to scale vertically, and are often a good first step prior to adding additional nodes. In addition, this will allow us to simplify support and improve maintainability for GitLab.com.
Directly invoking Sidekiq will no longer be supported as of 14.0.
For more information on falling back to the old (deprecated) behavior,
please refer to either Omnibus or
Helm charts docs.
Bug reports in this issue will be greatly appreciated.
Deprecation date:
May 22, 2020
Unicorn will be removed in favor of Puma
Unicorn support is deprecated and will be removed in GitLab 14.0. Learn more about migrating to Puma.
Deprecation date:
May 22, 2021
Removals
Auto DevOps' postgres chart upgrading to ver 7.7.3
As Kubernetes 1.16 no longer serves resources on the extensions/*
and apps/beta*
API endpoints, all dependent resources are upgraded to consume the new apps/v1
API endpoint.
If you are making use of the postgres database served by Auto DevOps, see the
migration guide
in order to backup your database, upgrade postgres version, and restore your database.
Removal date:
May 22, 2020
GitLab Pages auth_server attribute removed
The auth_server
setting (with an underscore [_]) for configuring access control when running GitLab Pages on a separate server was deprecated in a previous release in favor of the gitlab_server
setting. This change was made because the data that GitLab Pages gets from GitLab now extends beyond just authentication. The auth_server
setting has been removed in 13.0.
Removal date:
May 22, 2020
GitLab Snippets content search removal in 13.0
With the release of Versioned Snippets, files in Snippets are no longer available via search from the UI and API. Title and Description content will be accessible via search and API.
Removal date:
May 22, 2020.
NFS for Git repository storage deprecated
With the general availability of Gitaly Cluster in GitLab 13.0, we are deprecating NFS for Git storage. We
intend to remove support for NFS for Git repositories in GitLab 14.0. We are taking this action early to
communicate our intent clearly, and avoid customers purchasing expensive NFS appliances that are not needed.
We invite customers currently using NFS for Git repositories to begin planning their migration. There are multiple
use cases for NFS for Git storage, and we are working to address these in our
Gitaly Cluster roadmap.
Removal date:
May 22, 2020
PostgreSQL 9.6 and 10 removed no longer supported
The minimal required version of PostgreSQL for all self-managed installations is now PostgreSQL 11. PostgreSQL versions 9.6 and 10 have been from the Omnibus package and Helm charts. The removal of support for 9.6 and 10 allows us to build upon the latest features and performance improvements available in PostgreSQL 11. For more details, see the release post on PostgreSQL 11.
Removal date:
May 22, 2020
Protected path configuration removed from `gitlab.rb`
Configuration settings for protected path rate limits have been removed from gitlab.rb
. Configuration of protected paths was moved to the GitLab Admin UI in GitLab 12.4.
Removal date:
May 22, 2020
Redis 3 no longer supported
Redis 3 has reached end of life and is no longer supported starting in GitLab 13.0. The bundled Redis version was updated to Redis 5 in GitLab 12.7 and GitLab Cloud Native Chart 3.0.
Removal date:
May 22, 2020
Release API evidence_sha and evidence_file_path deprecated
Now that users can create Release Evidence on demand, GitLab supports multiple Evidence objects, each of which exposes the summary_sha
and filepath
fields. Access to the original Evidence object is separately available via the deprecated evidence_sha
and evidence_file_path
fields in the Releases API. Updates to 13.0 make it possible to continue using Release Evidence and to be able to leverage on demand evidence collection.
Removal date:
May 22, 2020
Release API evidence_sha and evidence_file_path removed
Now that users can create Release Evidence on demand, GitLab supports multiple Evidence objects, each of which exposes the summary_sha and filepath fields. The original Evidence object is accessible as the first instance of the multiple Evidence objects. Updates to 13.0 make it possible to continue using Release Evidence and to be able to leverage on demand evidence collection.
Removal date:
May 22, 2020
Remove --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
) has been removed. This means that the option gitlab-runner register --docker-services postgres
will no longer set the service, because the configuration is no longer an array of strings. You can find more details in issue #6404.
Removal date:
May 22, 2020
Remove Backported `os.Expand`
In GitLab Runner 13.0, we have removed the backported os.Expand()
from Go v1.10.8. This backport was needed to include a change in behavior introduced in Go v1.11. You can find more details in issue #4915.
Removal date:
May 22, 2020
Remove Fedora 29 package support
Since Fedora 29 has reached End of Life as of 2019-11-30, we have removed support for Fedora 29 packages in the GitLab Runner 13.0 release. You can find more details in issue #16158.
Removal date:
May 22, 2020
Remove Jenkins CI(deprecated) Service
In GitLab 8.3, the Jenkins integration using the GitLab Hook Plugin was deprecated in favor of the GitLab Plugin. In 13.0, this Jenkins CI(deprecated) service is removed in issue #1600.
Removal date:
May 22, 2020
Remove `FF_USE_LEGACY_VOLUMES_MOUNTING_ORDER` feature flag
In 12.0, we introduced a feature flag for the Docker executor that enabled you to continue using the method where volumes are not mounted to services. In 13.0, this feature flag has been removed and volumes will be mounted to services. You can find more details in issue #6581.
Removal date:
May 22, 2020
Remove legacy build directory caching
In GitLab Runner 13.0, we have removed the legacy build directory caching feature flag that was introduced in 11.10. You can find more details in issue #4180.
Removal date:
May 22, 2020
Remove macOS 32-bit support
As Go 1.14 is the last Go release to support 32-bit binaries on macOS (the Darwin/386 port), we have removed support for 32-bit macOS in the GitLab 13.0 release. GitLab Runner will continue to support the macOS 64-bit Darwin/AMD64 port. You can find more details in issue #25466.
Removal date:
May 22, 2020
Remove support for Windows Server 1803
We have removed support for Windows Server version 1803 in the GitLab Runner 13.0 release. You can find more details in issue #6553.
Removal date:
May 22, 2020
Remove support for array of strings when defining services for Docker executor
In GitLab Runner 13.0, we have reverted back to using the default TOML parsing instead of UnmarshalTOML
for the DockerService
. You can find more details in issue #4922.
Removal date:
May 22, 2020
Removed `debug/jobs/list?v=1` endpoint
In GitLab Runner 13.0, we have removed the /debug/jobs/list?v=1
endpoint used for monitoring. This is superseded by the /debug/jobs/list?v=2
endpoint. You can find more details in issue #6361.
Removal date:
May 22, 2020
`consul['user']` and `repmgr['user']` attributes removed from `gitlab.rb`
The consul['user']
and repmgr['user']
attributes were deprecated in favor of consul['username']
and repmgr['username']
in 12.10 to be consistent with other GitLab services that allow a username to be configured. These attributes have been removed in 13.0. If you are still using the user
attributes you will need to switch over to using the username
attributes.
Removal date:
May 22, 2020
`gitlab_monitor` attribute removed from `gitlab.rb`
The GitLab Monitor tool was renamed GitLab Exporter in 12.3 to prevent confusion with other monitoring-related features, and gitlab_exporter
keys were added to gitlab.rb
. The gitlab_monitor
keys were deprecated in 12.3 and have been removed in 13.0.
Removal date:
May 22, 2020