- Available feature flags
- Enable feature flag in pipeline configuration
- Enable feature flag in runner environment variables
- Enable feature flag in runner configuration
Introduced in GitLab 11.4.
Feature flags are toggles that allow you to enable or disable specific features. These flags are typically used:
For beta features that are made available for volunteers to test, but that are not ready to be enabled for all users.
Beta features are sometimes incomplete or need further testing. A user who wants to use a beta feature can choose to accept the risk and explicitly enable the feature with a feature flag. Other users who do not need the feature or who are not willing to accept the risk on their system have the feature disabled by default and are not impacted by possible bugs and regressions.
For breaking changes that result in functionality deprecation or feature removal in the near future.
As the product evolves, features are sometimes changed or removed entirely. Known bugs are often fixed, but in some cases, users have already found a workaround for a bug that affected them; forcing users to adopt the standardized bug fix might cause other problems with their customized configurations.
In such cases, the feature flag is used to switch from the old behavior to the new one on demand. This allows users to adopt new versions of the product while giving them time to plan for a smooth, permanent transition from the old behavior to the new behavior.
Feature flags are toggled using environment variables. To:
- Activate a feature flag, set the corresponding environment variable to
- Deactivate a feature flag, set the corresponding environment variable to
|Feature flag||Default value||Deprecated||To be removed with||Description|
|✗||Disables EnableDelayedExpansion for error checking for when using Window Batch shell|
|✗||Enables creation of a Docker network per build with the |
|✗||When set to |
|✗||When set to |
|✗||When set to |
|✓||14.0||Use the old process termination that was used prior to GitLab 13.1 where only |
|✓||14.0||Enables adding an ENTRYPOINT layer for Helper images imported from local Docker archives by the |
|✓||14.0||Enables the use of Go Cloud to write cache archives to object storage. This mode is only used by Azure Blob storage.|
|✗||Fastzip is a performant archiver for cache/artifact archiving and extraction|
|✗||Use GitLab Runner helper image for the Docker and Kubernetes executors from |
|✗||If enabled will remove the usage of |
|✗||If enabled, bash scripts don’t rely solely on |
|✗||When disabled, processes that Runner creates on Windows (shell and custom executor) will be created with additional setup that should improve process termination. This is currently experimental and how we setup these processes may change as we continue to improve this. When set to |
|✗||With the |
You can use CI variables to enable feature flags:
For all jobs in the pipeline (globally):
variables: FEATURE_FLAG_NAME: 1
For a single job:
job: stage: test variables: FEATURE_FLAG_NAME: 1 script: - echo "Hello"
[[runners]] name = "ruby-2.6-docker" url = "https://CI/" token = "TOKEN" limit = 0 executor = "docker" builds_dir = "" shell = "" environment = ["FEATURE_FLAG_NAME=1"]
Introduced in GitLab Runner 13.11.
You can enable feature flags by specifying them under
setting prevents any job from overriding the feature flag values.
Some feature flags are also only usable when you configure this setting, because they don’t deal with how the job is executed.
[[runners]] name = "ruby-2.6-docker" url = "https://CI/" token = "TOKEN" executor = "docker" [runners.feature_flags] FF_USE_DIRECT_DOWNLOAD = true