What a year 2020 has been! We're excited to share what's new in 13.7 with over 45 features and improvements shipping just in time for the holidays!
On behalf of everyone at GitLab, I want to take a second to thank everyone in our community for your contributions and the positive impact you've made. Without you, GitLab would not be what it is today.
Here's to you and all of our team members that helped make 2020 an incredible year despite the adversity and unprecedented times. Please continue staying safe, happy, and healthy this holiday season.
Here's what you can look forward to in 13.7:
Enhanced project management for cross-collaboration
Merge Requests (MRs) are crucial to foster cross-collaboration and can be directly linked to relevant issues, providing a central location to communicate via comments, suggest code changes, perform code reviews, and much more. In this release, we've added merge request reviewers, a capability to improve the code review process by making reviews easier and more organized. Now you'll be able to quickly find out who's involved in the merge request or request a formal review that will send them a notification.
Context switching and manual tasks in your workflow hinder your ability to efficiently collaborate across groups and projects. It means you spend less time developing valuable features and more time managing your projects, which is why the ability to clone issues with quick actions is so valuable for you to streamline agile planning and project management.
Collaborating on projects and iterating rapidly to develop your applications means you need to be able to quickly determine the order of importance of your issues, identify any blockers, and use that information to prioritize what you'll work on next. Now, you can sort issues by blockers to quickly find out which of your issues are blocking progress for other issues, as well as easily sort by the number of blockers in your issue list.
Improved release automation and deployment flexibility
You need flexibility to control how you orchestrate, automate, and deploy your applications on a regular basis. Deploying your applications reliably and frequently gets value into the hands of your customers sooner.
To improve how GitLab automates releases, we've added automatic rollback in case of failure. This feature automatically reverts an unsuccessful deployment back to the last successful deployment and sends an automatic notification to alert you of the status. You won't have to manually make any changes and can be confident that potential problems won't cause downtime or intensify while you work towards a fix.
An improvement that goes well with automatic rollback in the event of a failure is the ability to see the deployment status in the Environment page. Now you can easily find deployment statuses and identify what actions you need to take, such as stopping or rolling back a deployment.
We've also shipped the first officially supported beta of GitLab Runner container on Red Hat OpenShift and our Certified Runner Operator to give you more flexibility over how you release with GitLab. We're working to make this generally available soon, so stay tuned for more information in future releases.
More reliable and efficient package and dependency management
Your workflow depends on a wide variety of programming languages, binaries, integrations, and artifacts that are all important inputs or outputs as a result of your development process. The more efficiently you can manage your packages and dependencies, the less development time goes to waste, and with efficiency in mind, we've added the option to quickly find and view generic packages.
We've also made improvements to GitLab's Dependency Proxy, which, by the way, was made available in Core in GitLab 13.6.
You can now avoid Docker rate-limits and speed up your pipelines with the Dependency Proxy to assure confidence in reliability and improve efficiency when caching your container images hosted on DockerHub.
Another improvement that many of you in the community were anticipating, the Dependency Proxy now works with private projects and addresses the limitations that prevented those of you with private projects from taking advantage of this feature.
Last but not least, you'll be able to use pre-defined variables with the Dependency Proxy instead of relying on your own defined variables or hard-coding values in your gitlab.ci-yml
file. This provides a more scalable and efficient way to get started proxying and caching images.
And more
Check out a few other awesome features shipping in 13.7 below:
These are just a few highlights out of many new features and performance improvements. If you'd like to preview what's coming in next month’s release, check out our Upcoming Releases page as well as our 13.8 release kick off video.
Deprecations
CentOS 6 is no longer supported
CentOS 6 reached end of life in November 2020. GitLab 13.6 was the last supported version for deploying GitLab on CentOS 6. You are advised to upgrade to CentOS 7 or 8. Visit the deprecated OSes page for more information on the supported distributions.
Planned removal date:
November 22, 2020
Deprecate Container Registry log formatters
Currently, GitLab supports:
- Text, JSON, and logstash log formatting for app logs.
- Text, JSON, and combined log formatting for access logs.
We will deprecate both logstash and combined, unifying the formatters for both app and access logs with only two options text (for development) and JSON.
Planned removal date:
January 22nd, 2021
Deprecate Container Registry logging hooks
The Container Registry currently supports logging hooks that can only be used for email notifications.
These days, alerts based on log entries are commonly handled by separate tools. As far as we know, none of our users rely on this functionality and it is not used at GitLab either. The implementation of this feature is tightly coupled with the underlying logging library, which is a limitation for our ability to switch dependencies without affecting the available features.
In an effort to simplify the registry features and configurations, we will drop support for logging hooks.
Planned removal date:
January 22nd, 2021
Deprecate Container Registry maxidle and maxactive Redis pool settings
Some of the configuration settings that we currently expose for the Redis connection pool are tied to the underlying Redis client and do not have an equivalent in alternative libraries. As we start working on improving the Redis integration, such as adding support for Sentinel, we decided to start working towards replacing the current Redis client dependency with a more feature-rich alternative that can be better supported. To do this, we need to replace the current Redis pool configuration settings that are tied to the current client library.
We intend to:
- Remove the
redis.pool.maxidle
and redis.pool.maxactive
settings.
- Add
redis.pool.size
(maximum number of connections), redis.pool.minidle
(minimum number of idle connections), and redis.pool.maxlifetime
(maximum amount of time a connection may be reused) settings.
Planned removal date:
January 22nd, 2021
Deprecate Container Registry support for Bugsnag
Bugsnag is one of the error reporting services supported by the Container Registry. As far as we know, none of our users rely on this service, and at GitLab we use Sentry. In an effort to simplify and consolidate the supported error reporting services, we intend to add support for Sentry and remove support for Bugsnag.
Planned removal date:
January 22nd, 2021
Deprecate Container Registry support for NewRelic
NewRelic is one of the error reporting services supported by the Container Registry. As far as we know, none of our users rely on this service, and at GitLab we use Sentry. In an effort to simplify and consolidate the supported error reporting services, we intend to add support for Sentry and remove support for NewRelic.
Planned removal date:
January 22nd, 2021
Deprecate Container Registry support for TLS 1.0 and 1.1
Support for TLS 1.0 and TLS 1.1 has been deprecated and removed for GitLab for security reasons. We will do the same for the GitLab Container Registry, which currently supports 1.0 (default), 1.1, 1.2, and 1.3. and defaults to 1.0.
We will deprecate support for TLS 1.0 and TLS 1.1, showing a warning log message when these are used. Support for these versions will be removed and TLS 1.2 will become the default.
Planned removal date:
January 22nd, 2021
Deprecate one-click GitLab Managed Apps in GitLab 14.0
In GitLab 13.7 we are deprecating one-click install of GitLab Managed Apps. Although they made it very easy to get started with deploying to Kubernetes from GitLab, the overarching community feedback was that they were not flexible or customizable enough for real-world Kubernetes applications. Instead, our future direction will focus on installing apps on Kubernetes via GitLab CI/CD in order to provide a better balance between ease-of-use and expansive customization.
We plan to remove one-click Managed Apps completely in GitLab version 14.0. This will not affect how existing managed applications run inside your cluster, however, you’ll no longer have the ability to update modify those applications via the GitLab UI. We recommend cluster administrators plan to migrate any existing managed applications by reinstalling them either manually or via CI/CD. Migration instructions will be available in our documentation later.
Planned removal date:
December 17, 2020
Deprecate pulls that use v1 of the Docker registry API
GitLab is disabling pulls via the Docker registry v1 APIs on January 22nd, 2021. Deprecated by Docker in June, 2019, deprecating this feature allows the GitLab team to focus on features and fixes that provide you with more value and target current registry use cases.
Existing users of the v1 registry API on GitLab can move to the v2 registry API by completing the following steps:
- Update your Docker Engine to 17.12 or later so it is compatible with the v2 registry API.
- If you have content in GitLab that is in the v1 format, you can move it to the v2 format by using a newer Docker client (more recent than 1.12) to rebuild the image and push it to GitLab.
Planned removal date:
January 22nd, 2021
GitLab Runner installation to ignore the skel directory
In GitLab Runner 14.0, the installation process will ignore the skel
directory by default when creating the user home directory. Refer to issue #4845 for details.
Planned removal date:
Jun 22, 2021
Make pwsh the default shell for newly-registered Windows Runners
In GitLab Runner 13.2, PowerShell Core support was added to the Shell executor. In 14.0, pwsh
will be the default shell for newly-registered Windows runners. Windows CMD
will still be available as a shell option for Windows runners. Refer to issue #26419 for details.
Planned removal date:
Jun 22, 2021
PostgreSQL 11 support
PostgreSQL 12 will be the minimum required version in GitLab 14.0. It offers significant improvements to indexing, partitioning, and general performance benefits.
New installations of GitLab will default to PostgreSQL 12 starting with 13.7. To manually upgrade, run gitlab-ctl pg-upgrade.
Multi-node database instances will need to switch from repmgr to Patroni, prior to upgrading with Patroni. Geo secondaries can then be updated and re-synchronized.
Planned removal date:
Jun 22, 2021
Remove /usr/lib/gitlab-runner symlink from package
In GitLab Runner 13.3, a symlink was added from /user/lib/gitlab-runner/gitlab-runner
to /usr/bin/gitlab-runner
. In 14.0, we will remove this symlink and the runner will be installed in /usr/bin/gitlab-runner
. Refer to issue #26651 for details.
Planned removal date:
Jun 22, 2021
Remove FF_SHELL_EXECUTOR_USE_LEGACY_PROCESS_KILL feature flag
In GitLab Runner 13.1, issue #3376, we introduced sigterm
and then sigkill
to a process in the Shell executor. We also introduced a new feature flag, FF_SHELL_EXECUTOR_USE_LEGACY_PROCESS_KILL
, so you can use the previous process termination sequence. In GitLab Runner 14.0, issue #6413, we will remove the feature flag.
Planned removal date:
Jun 22, 2021
Remove FF_USE_GO_CLOUD_WITH_CACHE_ARCHIVER feature flag
In GitLab Runner 14.0, we will remove the FF_USE_GO_CLOUD_WITH_CACHE_ARCHIVER
feature flag. Refer to issue #27175 for details.
Planned removal date:
Jun 22, 2021
Remove Ubuntu 19.10 (Eoan Ermine) package
Ubuntu 19.10 (Eoan Ermine) reached end of life on Friday, July 17, 2020. In GitLab Runner 14.0, we will remove the Ubuntu 19.10 (Eoan Ermine) from our package distribution. Refer to issue #26036 for details.
Planned removal date:
Jun 22, 2021
Remove off peak time mode configuration for Docker Machine autoscaling
In GitLab Runner 13.0, issue #5069, we introduced new timing options for the GitLab Docker Machine executor. In GitLab Runner 14.0, we plan to remove the old configuration option, off peak time mode.
Planned removal date:
Jun 22, 2021
Remove success and failure for finished build metric conversion
In GitLab Runner 13.5, we introduced failed
and success
states for a job. To support Prometheus rules, we chose to convert success/failure
to finished
for the metric. In 14.0, we will remove the conversion. Refer to issue #26900 for details.
Planned removal date:
Jun 22, 2021
Remove translation from step_script to build_script in custom executor
In GitLab Runner 13.2 a translation for step_script
to build_script
was added to the custom executor. In 14.0 the build_script
stage will be replaced with step_script
. Refer to issue #26426 for details.
Planned removal date:
Jun 22, 2021
Require Git 2.29 or later
In GitLab 13.7 and later, GitLab requires Git 2.29 or later. Omnibus GitLab installations include Git 2.29. Installations from source must be upgraded manually.
Planned removal date:
November 22, 2020
Sidekiq Cluster queue selector configuration option has been renamed
GitLab contains a large number of background job queues. Some administrators may want to have multiple background job processes, each running different workloads.
Previously, we only supported specifying the queues handled for a particular process by name, or using an experimental option to allow selecting queues by attributes.
This option - previously experimental_queue_selector
- is no longer experimental and has been renamed to queue_selector
. experimental_queue_selector
will continue to work until GitLab 14.0.
Planned removal date:
June 22, 2021
We want to hear from you
Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.
Share your feedback