# Customizing Auto DevOps
> 原文：[https://docs.gitlab.com/ee/topics/autodevops/customize.html](https://docs.gitlab.com/ee/topics/autodevops/customize.html)
* [Custom buildpacks](#custom-buildpacks)
* [Multiple buildpacks](#multiple-buildpacks)
* [Custom `Dockerfile`](#custom-dockerfile)
* [Passing arguments to `docker build`](#passing-arguments-to-docker-build)
* [Forward CI variables to the build environment](#forward-ci-variables-to-the-build-environment)
* [Custom Helm Chart](#custom-helm-chart)
* [Customize values for Helm Chart](#customize-values-for-helm-chart)
* [Custom Helm chart per environment](#custom-helm-chart-per-environment)
* [Customizing `.gitlab-ci.yml`](#customizing-gitlab-ciyml)
* [Customizing the Kubernetes namespace](#customizing-the-kubernetes-namespace)
* [Using components of Auto DevOps](#using-components-of-auto-devops)
* [PostgreSQL database support](#postgresql-database-support)
* [Upgrading PostgresSQL](#upgrading-postgressql)
* [Using external PostgreSQL database providers](#using-external-postgresql-database-providers)
* [Environment variables](#environment-variables)
* [Build and deployment](#build-and-deployment)
* [Database](#database)
* [Disable jobs](#disable-jobs)
* [Application secret variables](#application-secret-variables)
* [Advanced replica variables setup](#advanced-replica-variables-setup)
* [Deploy policy for staging and production environments](#deploy-policy-for-staging-and-production-environments)
* [Deploy policy for canary environments](#deploy-policy-for-canary-environments-premium)
* [Incremental rollout to production](#incremental-rollout-to-production-premium)
* [Timed incremental rollout to production](#timed-incremental-rollout-to-production-premium)
* [Auto DevOps banner](#auto-devops-banner)
# Customizing Auto DevOps[](#customizing-auto-devops "Permalink")
尽管[Auto DevOps](index.html)提供了很好的默认设置来帮助您入门，但是您可以自定义几乎所有内容以满足您的需求. Auto DevOps 提供了从自定义[buildpacks](#custom-buildpacks)到[Dockerfiles](#custom-dockerfile)和[Helm 图表的所有内容](#custom-helm-chart) . 您甚至可以将完整的[CI / CD 配置](#customizing-gitlab-ciyml)复制到您的项目中，以启用暂存和 Canary 部署等.
## Custom buildpacks[](#custom-buildpacks "Permalink")
如果您的项目无法自动检测到构建包，或者要使用自定义构建包，则可以在项目中使用项目变量或`.buildpacks`文件覆盖`.buildpacks` ：
* **项目变量** -使用要使用的 buildpack 的 URL 创建项目变量`BUILDPACK_URL` .
* **`.buildpacks`文件** -在项目的存储库中添加一个名为`.buildpacks`的文件，并添加要在文件中一行使用的 buildpack 的 URL. 如果要使用多个 buildpack，请每行输入一个 buildpack.
buildpack URL 可以指向 Git 存储库 URL 或 tarball URL. 对于 Git 存储库，您可以通过将`#<ref>`附加到 Git 存储库 URL 来指向特定的 Git 引用（例如，提交 SHA，标记名称或分支名称）. 例如：
* 标签`v142` ： `https://github.com/heroku/heroku-buildpack-ruby.git#v142` : `https://github.com/heroku/heroku-buildpack-ruby.git#v142` .
* 分支`mybranch` ： `https://github.com/heroku/heroku-buildpack-ruby.git#mybranch` : `https://github.com/heroku/heroku-buildpack-ruby.git#mybranch` .
* 提交 SHA `f97d8a8ab49` ： `https://github.com/heroku/heroku-buildpack-ruby.git#f97d8a8ab49` : `https://github.com/heroku/heroku-buildpack-ruby.git#f97d8a8ab49` .
### Multiple buildpacks[](#multiple-buildpacks "Permalink")
Auto DevOps 不完全支持使用多个 buildpack，因为在使用`.buildpacks`文件时，自动测试将不起作用. 在后端用于解析`.buildpacks`文件的 buildpack [heroku-buildpack-multi](https://github.com/heroku/heroku-buildpack-multi/)没有提供必要的命令`bin/test-compile`和`bin/test` .
If your goal is to use only a single custom buildpack, you should provide the project variable `BUILDPACK_URL` instead.
## Custom `Dockerfile`[](#custom-dockerfile "Permalink")
> [在 GitLab 13.2](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/35662)中[添加了](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/35662)对`DOCKERFILE_PATH`支持
如果您的项目在项目存储库的根目录中有一个`Dockerfile` ，则 Auto DevOps 会基于 Dockerfile 而不是使用 buildpacks 构建 Docker 映像. 这样可以更快，并产生较小的映像，尤其是在您的 Dockerfile 基于[Alpine 的情况下](https://hub.docker.com/_/alpine/) .
如果设置`DOCKERFILE_PATH` CI 变量，则"自动构建"将在其中查找 Dockerfile.
## Passing arguments to `docker build`[](#passing-arguments-to-docker-build "Permalink")
可以使用`AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGS`项目变量将参数传递给`AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGS` `docker build`命令. 例如，要基于`ruby:alpine`而不是默认的`ruby:latest`构建 Docker 映像：
1. Set `AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGS` to `--build-arg=RUBY_VERSION=alpine`.
2. 将以下内容添加到自定义`Dockerfile` ：
```
ARG RUBY_VERSION=latest
FROM ruby:$RUBY_VERSION
# ... put your stuff here
```
**注意：**如果需要传递复杂的值（例如换行符和空格）， **请**使用 Base64 编码. 由于 Auto DevOps 如何使用自变量，此类未经编码的复杂值可能导致转义问题.**警告：**尽可能避免将秘密作为 Docker 构建参数传递，因为它们可能会保留在映像中. 有关详细信息，请参见[有关最佳实践的讨论](https://github.com/moby/moby/issues/13490) .
## Forward CI variables to the build environment[](#forward-ci-variables-to-the-build-environment "Permalink")
在 GitLab 12.3 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/25514) ，但在 11.9 及更高版本中可用.
可以使用`AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES` CI 变量将 CI 变量转发到构建环境中. 转发的变量应在逗号分隔的列表中按名称指定. 例如，要转发变量`CI_COMMIT_SHA`和`CI_ENVIRONMENT_NAME` ，请将`AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES`设置为`CI_COMMIT_SHA,CI_ENVIRONMENT_NAME` .
* 使用 Buildpacks 时，转发的变量将自动用作环境变量.
* 使用`Dockerfile` ，需要执行以下附加步骤：
1. 通过将以下代码添加到文件顶部来激活实验性`Dockerfile`语法：
```
# syntax = docker/dockerfile:experimental
```
2. 要在任何可用的秘密`RUN $COMMAND`在`Dockerfile` ，秘密文件和源安装运行之前，它`$COMMAND` ：
```
RUN --mount=type=secret,id=auto-devops-build-secrets . /run/secrets/auto-devops-build-secrets && $COMMAND
```
**注意：**设置`AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES` ，Auto DevOps 会启用实验性[Docker BuildKit](https://s0docs0docker0com.icopy.site/develop/develop-images/build_enhancements/)功能以使用`--secret`标志.
## Custom Helm Chart[](#custom-helm-chart "Permalink")
Auto DevOps 使用[Helm](https://helm.sh/)将您的应用程序部署到 Kubernetes. 您可以通过将图表捆绑到项目存储库中或通过指定项目变量来覆盖使用的 Helm 图表：
* **捆绑图** -如果您的项目中有一个带有`Chart.yaml`文件的`./chart`目录，则 Auto DevOps 将检测到该图并使用它代替[默认图](https://gitlab.com/gitlab-org/charts/auto-deploy-app) ，从而使您能够精确地控制应用程序的部署方式.
* **项目变量** -创建一个[项目变量](../../ci/variables/README.html#gitlab-cicd-environment-variables) `AUTO_DEVOPS_CHART`有一个自定义图表的 URL 来使用，或创建两个项目变量： `AUTO_DEVOPS_CHART_REPOSITORY`有一个自定义图表库的 URL，并`AUTO_DEVOPS_CHART`与路径图.
## Customize values for Helm Chart[](#customize-values-for-helm-chart "Permalink")
[介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/30628)在 GitLab 12.6， `.gitlab/auto-deploy-values.yaml`将默认为头盔升级使用.
您可以通过以下任一方式覆盖[默认 Helm 图表中](https://gitlab.com/gitlab-org/charts/auto-deploy-app) `values.yaml`文件中的[默认值](https://gitlab.com/gitlab-org/charts/auto-deploy-app) ：
* 将名为`.gitlab/auto-deploy-values.yaml`的文件添加到您的存储库，如果找到，该文件将自动使用.
* 将具有不同名称或路径的文件添加到存储库，并使用路径和名称设置`HELM_UPGRADE_VALUES_FILE` [环境变量](#environment-variables) .
**注：**对于 GitLab 12.5 和更早的版本，使用`HELM_UPGRADE_EXTRA_ARGS`环境变量设置以覆盖默认图表值`HELM_UPGRADE_EXTRA_ARGS`到`--values <my-values.yaml>`
## Custom Helm chart per environment[](#custom-helm-chart-per-environment "Permalink")
您可以通过将环境变量定义为所需环境来指定每个环境使用自定义 Helm 图表. 请参阅[限制变量的环境范围](../../ci/variables/README.html#limit-the-environment-scopes-of-environment-variables) .
## Customizing `.gitlab-ci.yml`[](#customizing-gitlab-ciyml "Permalink")
Auto DevOps 是完全可自定义的，因为[Auto DevOps 模板](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml)只是[`.gitlab-ci.yml`](../../ci/yaml/README.html)文件的实现，并且仅使用任何`.gitlab-ci.yml`实现的`.gitlab-ci.yml` .
要修改 Auto DevOps 使用的 CI / CD 管道，请[`include`模板](../../ci/yaml/README.html#includetemplate) ，并根据需要通过向包含以下内容的存储库的根目录中添加`.gitlab-ci.yml`文件来自定义它：
```
include:
- template: Auto-DevOps.gitlab-ci.yml
```
添加您的更改，您的添加将使用[`include`](../../ci/yaml/README.html#include)所描述的行为与[Auto DevOps 模板](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml)合并.
如果您需要专门删除文件的一部分，还可以将[Auto DevOps 模板](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml)的内容复制并粘贴到您的项目中，并根据需要进行编辑.
## Customizing the Kubernetes namespace[](#customizing-the-kubernetes-namespace "Permalink")
在 GitLab 12.6 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/27630) .
对于不受 GitLab 管理的集群，可以通过指定[`environment:kubernetes:namespace`](../../ci/environments/index.html#configuring-kubernetes-deployments)来自定义`.gitlab-ci.yml`的[`environment:kubernetes:namespace`](../../ci/environments/index.html#configuring-kubernetes-deployments) . 例如，以下配置将覆盖用于`production`部署的名称空间：
```
include:
- template: Auto-DevOps.gitlab-ci.yml
production:
environment:
kubernetes:
namespace: production
```
使用 Auto DevOps 部署到自定义名称空间时，群集随附的服务帐户至少需要名称空间内的`edit`角色.
* 如果服务帐户可以创建名称空间，则可以按需创建名称空间.
* 否则，名称空间必须在部署之前存在.
## Using components of Auto DevOps[](#using-components-of-auto-devops "Permalink")
如果仅需要 Auto DevOps 提供的功能的子集，则可以将各个 Auto DevOps 作业包括在自己的`.gitlab-ci.yml` . 每个组件作业都依赖于一个阶段，该阶段应该在包含模板的`.gitlab-ci.yml`中定义.
例如，要使用[自动构建](stages.html#auto-build) ，可以将以下内容添加到`.gitlab-ci.yml` ：
```
stages:
- build
include:
- template: Jobs/Build.gitlab-ci.yml
```
有关可用作业的信息，请参见[Auto DevOps 模板](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml) .
**弃用：**从[GitLab 13.0](https://gitlab.com/gitlab-org/gitlab/-/issues/213336)开始，使用[`only`](../../ci/yaml/README.html#onlyexcept-basic)或[`except`](../../ci/yaml/README.html#onlyexcept-basic)语法的 Auto DevOps 模板将切换到[`rules`](../../ci/yaml/README.html#rules)语法. 如果您`.gitlab-ci.yml`扩展了这些汽车的 DevOps 模板和覆盖`only`或`except`关键字，您必须迁移模板使用[`rules`](../../ci/yaml/README.html#rules)语法的基本模板被迁移到使用后`rules`语法. 对于尚不能迁移的用户，您可以选择将模板固定到[基于 GitLab 12.10 的模板](https://gitlab.com/gitlab-org/auto-devops-v12-10) .
## PostgreSQL database support[](#postgresql-database-support "Permalink")
为了支持需要数据库的应用程序，默认情况下配置[PostgreSQL](https://s0www0postgresql0org.icopy.site/) . 访问数据库的凭据已预先配置，但可以通过设置关联[变量](#environment-variables)进行自定义. 您可以使用这些凭据来定义`DATABASE_URL` ：
```
postgres://user:password@postgres-host:postgres-port/postgres-database
```
### Upgrading PostgresSQL[](#upgrading-postgressql "Permalink")
**弃用：**用于控制默认`AUTO_DEVOPS_POSTGRES_CHANNEL`配置 PostgreSQL 的变量`AUTO_DEVOPS_POSTGRES_CHANNEL`在[GitLab 13.0 中](https://gitlab.com/gitlab-org/gitlab/-/issues/210499)已更改为`2` . 要继续使用旧的 PostgreSQL，请将`AUTO_DEVOPS_POSTGRES_CHANNEL`变量设置为`1` .
用于配置 PostgreSQL 的图表的版本：
* 在 GitLab 13.0 和更高版本中为 8.2.1，但如果需要可以将其设置回 0.7.1.
* 可以在 GitLab 12.9 和 12.10 中设置为 0.7.1 至 8.2.1.
* 在 GitLab 12.8 及更早版本中为 0.7.1.
GitLab 鼓励用户[将其数据库迁移](upgrading_postgresql.html)到较新的 PostgreSQL.
### Using external PostgreSQL database providers[](#using-external-postgresql-database-providers "Permalink")
尽管 Auto DevOps 为生产环境提供了对 PostgreSQL 容器的开箱即用支持，但在某些情况下，它可能不够安全或没有弹性，您可能要使用外部托管提供程序（例如 AWS Relational Database）服务）（适用于 PostgreSQL）.
您必须在项目的 CI / CD 设置中为`POSTGRES_ENABLED`和`DATABASE_URL`定义环境范围的变量：
1. 使用范围内的[环境变量](../../ci/environments/index.html#scoping-environments-with-specs)针对所需环境禁用内置 PostgreSQL 安装. 对于此用例，可能只需要将`production`添加到此列表中. 用于 Review Apps 和登台的内置 PostgreSQL 设置就足够了.
[](img/disable_postgres.png)
2. Define the `DATABASE_URL` CI variable as a scoped environment variable that will be available to your application. This should be a URL in the following format:
```
postgres://user:password@postgres-host:postgres-port/postgres-database
```
您必须确保您的 Kubernetes 集群可以访问托管 PostgreSQL 的任何地方的网络.
## Environment variables[](#environment-variables "Permalink")
以下变量可用于设置 Auto DevOps 域，提供自定义 Helm 图表或缩放应用程序. PostgreSQL 也可以自定义，您可以使用[自定义 buildpack](#custom-buildpacks) .
### Build and deployment[](#build-and-deployment "Permalink")
下表列出了与构建和部署应用程序有关的变量.
| **Variable** | **Description** |
| --- | --- |
| `ADDITIONAL_HOSTS` | 指定为逗号分隔列表的标准域名，添加到 Ingress 主机中. |
| `<ENVIRONMENT>_ADDITIONAL_HOSTS` | 对于特定环境，将指定为逗号分隔列表的标准域名添加到 Ingress 主机. 这优先于`ADDITIONAL_HOSTS` . |
| `AUTO_DEVOPS_ATOMIC_RELEASE` | 从 GitLab 13.0 开始，默认情况下，Auto DevOps 使用[`--atomic`](https://v2.helm.sh/docs/helm/#options-43)进行 Helm 部署. 将此变量设置为`false`可禁用`--atomic` |
| `AUTO_DEVOPS_BUILD_IMAGE_CNB_ENABLED` | 当设置为非空值且不存在`Dockerfile` ，"自动构建"将使用 Cloud Native Buildpacks 而非 Herokuish 构建应用程序. [更多细节](stages.html#auto-build-using-cloud-native-buildpacks-beta) . |
| `AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDER` | 使用 Cloud Native Buildpacks 构建时使用的构建器. 默认的构建器是`heroku/buildpacks:18` . [更多细节](stages.html#auto-build-using-cloud-native-buildpacks-beta) . |
| `AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGS` | 要传递给`docker build`命令的额外参数. 请注意，使用引号不会阻止单词拆分. [更多细节](#passing-arguments-to-docker-build) . |
| `AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES` | A [comma-separated list of CI variable names](#forward-ci-variables-to-the-build-environment) to be forwarded to the build environment (the buildpack builder or `docker build`). |
| `AUTO_DEVOPS_CHART` | Helm Chart 用于部署您的应用程序. 默认为[GitLab 提供的](https://gitlab.com/gitlab-org/charts/auto-deploy-app) . |
| `AUTO_DEVOPS_CHART_REPOSITORY` | Helm Chart 存储库用于搜索图表. 默认为`https://charts.gitlab.io` . |
| `AUTO_DEVOPS_CHART_REPOSITORY_NAME` | 从 GitLab 11.11 开始，用于设置 Helm 存储库的名称. 默认为`gitlab` . |
| `AUTO_DEVOPS_CHART_REPOSITORY_USERNAME` | 从 GitLab 11.11 开始，用于设置用户名以连接到 Helm 存储库. 默认为无凭据. 还要设置`AUTO_DEVOPS_CHART_REPOSITORY_PASSWORD` . |
| `AUTO_DEVOPS_CHART_REPOSITORY_PASSWORD` | 从 GitLab 11.11 开始，用于设置密码以连接到 Helm 存储库. 默认为无凭据. 还要设置`AUTO_DEVOPS_CHART_REPOSITORY_USERNAME` . |
| `AUTO_DEVOPS_DEPLOY_DEBUG` | 从 GitLab 13.1 开始，如果存在此变量，Helm 将输出调试日志. |
| `AUTO_DEVOPS_ALLOW_TO_FORCE_DEPLOY_V<N>` | 从[auto-deploy-image](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image) v1.0.0 起，如果存在此变量，则将强制部署新的主要图表版本. [更多细节](upgrading_chart.html#ignore-warning-and-continue-deploying) |
| `AUTO_DEVOPS_MODSECURITY_SEC_RULE_ENGINE` | 从 GitLab 12.5 起，与[ModSecurity 功能标记](../../user/clusters/applications.html#web-application-firewall-modsecurity)结合使用可切换[ModSecurity 的`SecRuleEngine`](https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)#SecRuleEngine)行为. 默认为`DetectionOnly` . |
| `BUILDPACK_URL` | Buildpack’s full URL. Can point to either [a Git repository URL or a tarball URL](#custom-buildpacks). |
| `CANARY_ENABLED` | 从 GitLab 11.0 开始，用于定义[Canary 环境](#deploy-policy-for-canary-environments-premium)的[部署策略](#deploy-policy-for-canary-environments-premium) . |
| `CANARY_PRODUCTION_REPLICAS` | 要在生产环境中为[Canary 部署](../../user/project/canary_deployments.html)进行部署的 Canary 副本数. 优先于`CANARY_REPLICAS` . 默认为 1. |
| `CANARY_REPLICAS` | 用于[Canary 部署](../../user/project/canary_deployments.html)的 Canary 副本数. 默认为 1. |
| `DOCKERFILE_PATH` | 从 GitLab 13.2 开始，允许[在构建阶段](#custom-dockerfile)覆盖[默认的 Dockerfile 路径](#custom-dockerfile) |
| `HELM_RELEASE_NAME` | 从 GitLab 12.1 起，可以覆盖`helm`发布名称. 将多个项目部署到单个名称空间时，可用于分配唯一的发行版名称. |
| `HELM_UPGRADE_VALUES_FILE` | 从 GitLab 12.6 起，可以覆盖`helm upgrade`值文件. 默认为`.gitlab/auto-deploy-values.yaml` . |
| `HELM_UPGRADE_EXTRA_ARGS` | 从 GitLab 11.11 开始，在部署应用程序时允许在`helm`命令中使用其他参数. 请注意，使用引号不会阻止单词拆分. |
| `INCREMENTAL_ROLLOUT_MODE` | 从 GitLab 11.4 起，如果存在的话，可用于为生产环境启用应用程序的[增量部署](#incremental-rollout-to-production-premium) . 对于手动部署作业，设置为" `manual` ；对于自动部署部署，则设置为" `timed` ，每个延迟 5 分钟. |
| `K8S_SECRET_*` | 从 GitLab 11.7 开始，Auto DevOps 会将任何前缀为[`K8S_SECRET_`](#application-secret-variables)变量作为环境变量提供给已部署的应用程序. |
| `KUBE_INGRESS_BASE_DOMAIN` | 从 GitLab 11.8 开始，可用于为每个群集设置一个域. 有关更多信息，请参见[群集域](../../user/project/clusters/index.html#base-domain) . |
| `PRODUCTION_REPLICAS` | 要在生产环境中部署的副本数. 优先于`REPLICAS` ，默认值为 1.对于零停机升级，设置为 2 或更大. |
| `REPLICAS` | 要部署的副本数. 默认为 1. |
| `ROLLOUT_RESOURCE_TYPE` | 从 GitLab 11.9 开始，允许使用自定义 Helm 图表指定正在部署的资源类型. 默认值为`deployment` . |
| `ROLLOUT_STATUS_DISABLED` | 从 GitLab 12.0 开始，用于禁用推出状态检查，因为它不支持所有资源类型，例如`cronjob` . |
| `STAGING_ENABLED` | 从 GitLab 10.8 开始，用于定义[登台和生产环境](#deploy-policy-for-staging-and-production-environments)的[部署策略](#deploy-policy-for-staging-and-production-environments) . |
**提示：**使用[项目变量](../../ci/variables/README.html#gitlab-cicd-environment-variables)设置副本[变量后](../../ci/variables/README.html#gitlab-cicd-environment-variables) ，可以通过重新部署来缩放应用程序.**注意：**您*不*应该直接扩展使用 Kubernetes 您的应用程序. 这可能会导致 Helm 无法检测到更改而造成混乱，随后使用 Auto DevOps 进行的部署可能会撤消您的更改.
### Database[](#database "Permalink")
下表列出了与数据库有关的变量.
| **Variable** | **Description** |
| --- | --- |
| `DB_INITIALIZE` | 从 GitLab 11.4 开始，用于指定运行以初始化应用程序的 PostgreSQL 数据库的命令. 在应用程序窗格中运行. |
| `DB_MIGRATE` | 从 GitLab 11.4 开始，用于指定运行以迁移应用程序的 PostgreSQL 数据库的命令. 在应用程序窗格中运行. |
| `POSTGRES_ENABLED` | 是否启用 PostgreSQL. 默认为`true` . 设置为`false`可禁用 PostgreSQL 的自动部署. |
| `POSTGRES_USER` | PostgreSQL 用户. 默认为`user` . 将其设置为使用自定义用户名. |
| `POSTGRES_PASSWORD` | PostgreSQL 密码. 默认为`testing-password` . 将其设置为使用自定义密码. |
| `POSTGRES_DB` | PostgreSQL 数据库名称. 默认为[`$CI_ENVIRONMENT_SLUG`](../../ci/variables/README.html#predefined-environment-variables)的值. 将其设置为使用自定义数据库名称. |
| `POSTGRES_VERSION` | 用于[`postgres` Docker 映像的](https://hub.docker.com/_/postgres)标签. 对于`9.6.16` GitLab 13.0 `9.6.16`的测试和部署，默认值为`9.6.16` （以前为`9.6.2` ）. 如果`AUTO_DEVOPS_POSTGRES_CHANNEL`设置为`1` ，则部署将使用默认版本`9.6.2` . |
### Disable jobs[](#disable-jobs "Permalink")
下表列出了用于禁用作业的变量.
| **Variable** | **Description** |
| --- | --- |
| `CODE_QUALITY_DISABLED` | 从 GitLab 11.0 起，用于禁用`codequality`作业. 如果存在变量，则不会创建作业. |
| `CONTAINER_SCANNING_DISABLED` | From GitLab 11.0, used to disable the `sast:container` job. If the variable is present, the job won’t be created. |
| `DAST_DISABLED` | 从 GitLab 11.0 起，用于禁用`dast`作业. 如果存在变量，则不会创建作业. |
| `DEPENDENCY_SCANNING_DISABLED` | 从 GitLab 11.0 起，用于禁用`dependency_scanning`作业. 如果存在变量，则不会创建作业. |
| `LICENSE_MANAGEMENT_DISABLED` | 从 GitLab 11.0 开始，用于禁用`license_management`作业. 如果存在变量，则不会创建作业. |
| `PERFORMANCE_DISABLED` | 从 GitLab 11.0 起，用于禁用浏览器`performance`作业. 如果存在变量，则不会创建作业. |
| `LOAD_PERFORMANCE_DISABLED` | 从 GitLab 13.2 开始，用于禁用`load_performance`作业. 如果存在变量，则不会创建作业. |
| `REVIEW_DISABLED` | 从 GitLab 11.0 开始，用于禁用`review`和手动`review:stop`作业. 如果存在该变量，则不会创建这些作业. |
| `SAST_DISABLED` | 从 GitLab 11.0 起，用于禁用`sast`作业. 如果存在变量，则不会创建作业. |
| `TEST_DISABLED` | 从 GitLab 11.0 起，用于禁用`test`作业. 如果存在变量，则不会创建作业. |
### Application secret variables[](#application-secret-variables "Permalink")
在 GitLab 11.7 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/49056) .
某些应用程序需要定义可由部署的应用程序访问的秘密变量. Auto DevOps 会检测以`K8S_SECRET_`开头的变量，并将这些带前缀的变量作为环境变量提供给已部署的应用程序.
要配置您的应用程序变量：
1. Go to your project’s **设置> CI / CD**, then expand the **Variables** section.
2. 创建一个 CI / CD 变量，确保密钥以`K8S_SECRET_`为前缀. 例如，您可以使用键`K8S_SECRET_RAILS_MASTER_KEY`创建一个变量.
3. 通过手动创建新管道或将代码更改推送到 GitLab 来运行 Auto DevOps 管道.
Auto DevOps 管道将使用您的应用程序秘密变量来填充 Kubernetes 秘密. 这个秘密在每个环境中都是唯一的. 部署应用程序时，机密将作为环境变量加载到运行应用程序的容器中. 在上面的示例之后，您可以在下面看到包含`RAILS_MASTER_KEY`变量的机密.
```
$ kubectl get secret production-secret -n minimal-ruby-app-54 -o yaml
apiVersion: v1
data:
RAILS_MASTER_KEY: MTIzNC10ZXN0
kind: Secret
metadata:
creationTimestamp: 2018-12-20T01:48:26Z
name: production-secret
namespace: minimal-ruby-app-54
resourceVersion: "429422"
selfLink: /api/v1/namespaces/minimal-ruby-app-54/secrets/production-secret
uid: 57ac2bfd-03f9-11e9-b812-42010a9400e4
type: Opaque
```
通常认为环境变量在 Kubernetes 容器中是不可变的. 如果在不更改任何代码的情况下更新应用程序机密，然后手动创建新管道，则会发现任何正在运行的应用程序吊舱都不会具有更新后的机密. 要更新机密，请执行以下任一操作：
* 将代码更新推送到 GitLab，以强制 Kubernetes 部署重新创建 Pod.
* 手动删除正在运行的 Pod，以使 Kubernetes 创建具有更新机密的新 Pod.
**注意：**由于当前 Auto DevOps 脚本环境的限制，当前不支持具有多行值的变量.
### Advanced replica variables setup[](#advanced-replica-variables-setup "Permalink")
除了上面提到的两个与副本相关的生产变量之外，您还可以将其他变量用于不同的环境.
Kubernetes 的标签名为`track` ，GitLab CI / CD 环境名称和副本环境变量被组合为`TRACK_ENV_REPLICAS`格式，使您能够定义自己的变量来扩展 Pod 的副本：
* `TRACK` ：Helm Chart 应用程序定义中`track` [Kubernetes 标签](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)的大写值. 如果未设置，则不会考虑到变量名.
* `ENV` ：部署作业的大写环境名称，在`.gitlab-ci.yml`设置.
在下面的示例中，环境的名称为`qa` ，并且部署了轨道`foo` ，这将导致一个名为`FOO_QA_REPLICAS`的环境变量：
```
QA testing:
stage: deploy
environment:
name: qa
script:
- deploy foo
```
还必须在应用程序的 Helm 图表中定义被引用的`foo`轨道，例如：
```
replicaCount: 1
image:
repository: gitlab.example.com/group/project
tag: stable
pullPolicy: Always
secrets:
- name: gitlab-registry
application:
track: foo
tier: web
service:
enabled: true
name: web
type: ClusterIP
url: http://my.host.com/
externalPort: 5000
internalPort: 5000
```
### Deploy policy for staging and production environments[](#deploy-policy-for-staging-and-production-environments "Permalink")
在 GitLab 10.8 中[引入](https://gitlab.com/gitlab-org/gitlab-ci-yml/-/merge_requests/160) .
**提示：**您也可以在[项目的设置中进行设置](index.html#deployment-strategy) .
Auto DevOps 的正常行为是使用连续部署，每次在默认分支上运行新管道时，都会自动推送到`production`环境. 但是，在某些情况下，您可能需要使用暂存环境并手动部署到生产环境. 对于这种情况，引入了`STAGING_ENABLED`环境变量.
如果您定义`STAGING_ENABLED` ，例如将`STAGING_ENABLED`设置为`1`作为 CI / CD 变量，则 GitLab 会自动将应用程序部署到`staging`环境，并在准备好手动部署到生产环境时为您创建`production_manual`作业.
### Deploy policy for canary environments[](#deploy-policy-for-canary-environments-premium "Permalink")
在 GitLab 11.0 中[引入](https://gitlab.com/gitlab-org/gitlab-ci-yml/-/merge_requests/171) .
在将任何更改部署到生产之前，可以使用[Canary 环境](../../user/project/canary_deployments.html) .
如果您在项目中定义`CANARY_ENABLED` ，例如将`CANARY_ENABLED`设置为`1`作为 CI / CD 变量，则会创建两个手动作业：
* `canary` -将应用程序部署到金丝雀环境.
* `production_manual`手动将应用程序部署到生产环境.
### Incremental rollout to production[](#incremental-rollout-to-production-premium "Permalink")
在 GitLab 10.8 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/5415) .
**提示：**您也可以在[项目的设置中进行设置](index.html#deployment-strategy) .
当您准备将新版本的应用程序部署到生产环境时，您可能希望使用增量部署将最新的代码替换为少数 Pod，以检查应用程序的行为，然后手动将部署率提高到 100％ .
如果在项目中将`INCREMENTAL_ROLLOUT_MODE`设置为`manual` ，则将创建 4 个不同的[手动](../../ci/pipelines/index.html#add-manual-interaction-to-your-pipeline)作业，而不是标准`production`作业：
1. `rollout 10%`
2. `rollout 25%`
3. `rollout 50%`
4. `rollout 100%`
该百分比基于`REPLICAS`变量，并定义了您要用于部署的 Pod 数量. 如果该值为`10` ，并且您运行`10%`部署作业，那么将有`1`新容器+ `9`个旧容器.
要开始工作，请点击播放图标（ ）旁边的职位名称. 您不需要从`10%`增加到`100%` ，您可以跳到所需的任何工作. 您也可以在达到`100%`之前通过执行较低百分比的作业来缩小规模. 一旦达到`100%` ，您将无法缩小规模，并且必须通过使用环境页面中的" [回滚"按钮](../../ci/environments/index.html#retrying-and-rolling-back)重新部署旧版本来进行[回滚](../../ci/environments/index.html#retrying-and-rolling-back) .
在下面，您可以看到如果定义了发布或登台变量，管道的外观.
没有`INCREMENTAL_ROLLOUT_MODE`和`STAGING_ENABLED` ：
[](img/rollout_staging_disabled.png)
没有`INCREMENTAL_ROLLOUT_MODE`和`STAGING_ENABLED` ：
[](img/staging_enabled.png)
在将`INCREMENTAL_ROLLOUT_MODE`设置为`manual`且没有`STAGING_ENABLED`情况`STAGING_ENABLED` ：
[](img/rollout_enabled.png)
将`INCREMENTAL_ROLLOUT_MODE`设置为`manual` ，并将`STAGING_ENABLED`
[](img/rollout_staging_enabled.png)
**注意：**在 GitLab 11.4 之前， `INCREMENTAL_ROLLOUT_ENABLED`环境变量的存在启用了此功能. 此配置已弃用，以后将被删除.
### Timed incremental rollout to production[](#timed-incremental-rollout-to-production-premium "Permalink")
在 GitLab 11.4 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/7545) .
**提示：**您也可以在[项目的设置中进行设置](index.html#deployment-strategy) .
此配置基于[向生产的增量部署](#incremental-rollout-to-production-premium) .
除以下内容外，其他所有行为均相同：
* 要启用它，请将`INCREMENTAL_ROLLOUT_MODE`变量设置为`timed` .
* Instead of the standard `production` job, the following jobs are created with a 5 minute delay between each:
1. `timed rollout 10%`
2. `timed rollout 25%`
3. `timed rollout 50%`
4. `timed rollout 100%`
## Auto DevOps banner[](#auto-devops-banner "Permalink")
在未启用自动 DevOps 的情况下，对新项目具有维护者或更高权限的用户将显示以下 Auto DevOps 标语：
[](img/autodevops_banner_v12_6.png)
可以为以下内容禁用横幅：
* 用户，当他们自己关闭它时.
* 通过显式[禁用 Auto DevOps 的项目](index.html#enablingdisabling-auto-devops) .
* 整个 GitLab 实例：
* 由管理员在 Rails 控制台中运行以下命令：
```
Feature . enable ( :auto_devops_banner_disabled )
```
* 通过带有管理员访问令牌的 REST API：
```
curl --data "value=true" --header "PRIVATE-TOKEN: <personal_access_token>" https://gitlab.example.com/api/v4/features/auto_devops_banner_disabled
```
- GitLab Docs
- Installation
- Requirements
- GitLab cloud native Helm Chart
- Install GitLab with Docker
- Installation from source
- Install GitLab on Microsoft Azure
- Installing GitLab on Google Cloud Platform
- Installing GitLab on Amazon Web Services (AWS)
- Analytics
- Code Review Analytics
- Productivity Analytics
- Value Stream Analytics
- Kubernetes clusters
- Adding and removing Kubernetes clusters
- Adding EKS clusters
- Adding GKE clusters
- Group-level Kubernetes clusters
- Instance-level Kubernetes clusters
- Canary Deployments
- Cluster Environments
- Deploy Boards
- GitLab Managed Apps
- Crossplane configuration
- Cluster management project (alpha)
- Kubernetes Logs
- Runbooks
- Serverless
- Deploying AWS Lambda function using GitLab CI/CD
- Securing your deployed applications
- Groups
- Contribution Analytics
- Custom group-level project templates
- Epics
- Manage epics
- Group Import/Export
- Insights
- Issues Analytics
- Iterations
- Public access
- SAML SSO for GitLab.com groups
- SCIM provisioning using SAML SSO for GitLab.com groups
- Subgroups
- Roadmap
- Projects
- GitLab Secure
- Security Configuration
- Container Scanning
- Dependency Scanning
- Dependency List
- Static Application Security Testing (SAST)
- Secret Detection
- Dynamic Application Security Testing (DAST)
- GitLab Security Dashboard
- Offline environments
- Standalone Vulnerability pages
- Security scanner integration
- Badges
- Bulk editing issues and merge requests at the project level
- Code Owners
- Compliance
- License Compliance
- Compliance Dashboard
- Create a project
- Description templates
- Deploy Keys
- Deploy Tokens
- File finder
- Project integrations
- Integrations
- Atlassian Bamboo CI Service
- Bugzilla Service
- Custom Issue Tracker service
- Discord Notifications service
- Enabling emails on push
- GitHub project integration
- Hangouts Chat service
- Atlassian HipChat
- Irker IRC Gateway
- GitLab Jira integration
- Mattermost Notifications Service
- Mattermost slash commands
- Microsoft Teams service
- Mock CI Service
- Prometheus integration
- Redmine Service
- Slack Notifications Service
- Slack slash commands
- GitLab Slack application
- Webhooks
- YouTrack Service
- Insights
- Issues
- Crosslinking Issues
- Design Management
- Confidential issues
- Due dates
- Issue Boards
- Issue Data and Actions
- Labels
- Managing issues
- Milestones
- Multiple Assignees for Issues
- Related issues
- Service Desk
- Sorting and ordering issue lists
- Issue weight
- Associate a Zoom meeting with an issue
- Merge requests
- Allow collaboration on merge requests across forks
- Merge Request Approvals
- Browser Performance Testing
- How to create a merge request
- Cherry-pick changes
- Code Quality
- Load Performance Testing
- Merge Request dependencies
- Fast-forward merge requests
- Merge when pipeline succeeds
- Merge request conflict resolution
- Reverting changes
- Reviewing and managing merge requests
- Squash and merge
- Merge requests versions
- Draft merge requests
- Members of a project
- Migrating projects to a GitLab instance
- Import your project from Bitbucket Cloud to GitLab
- Import your project from Bitbucket Server to GitLab
- Migrating from ClearCase
- Migrating from CVS
- Import your project from FogBugz to GitLab
- Gemnasium
- Import your project from GitHub to GitLab
- Project importing from GitLab.com to your private GitLab instance
- Import your project from Gitea to GitLab
- Import your Jira project issues to GitLab
- Migrating from Perforce Helix
- Import Phabricator tasks into a GitLab project
- Import multiple repositories by uploading a manifest file
- Import project from repo by URL
- Migrating from SVN to GitLab
- Migrating from TFVC to Git
- Push Options
- Releases
- Repository
- Branches
- Git Attributes
- File Locking
- Git file blame
- Git file history
- Repository mirroring
- Protected branches
- Protected tags
- Push Rules
- Reduce repository size
- Signing commits with GPG
- Syntax Highlighting
- GitLab Web Editor
- Web IDE
- Requirements Management
- Project settings
- Project import/export
- Project access tokens (Alpha)
- Share Projects with other Groups
- Snippets
- Static Site Editor
- Wiki
- Project operations
- Monitor metrics for your CI/CD environment
- Set up alerts for Prometheus metrics
- Embedding metric charts within GitLab-flavored Markdown
- Embedding Grafana charts
- Using the Metrics Dashboard
- Dashboard YAML properties
- Metrics dashboard settings
- Panel types for dashboards
- Using Variables
- Templating variables for metrics dashboards
- Prometheus Metrics library
- Monitoring AWS Resources
- Monitoring HAProxy
- Monitoring Kubernetes
- Monitoring NGINX
- Monitoring NGINX Ingress Controller
- Monitoring NGINX Ingress Controller with VTS metrics
- Alert Management
- Error Tracking
- Tracing
- Incident Management
- GitLab Status Page
- Feature Flags
- GitLab CI/CD
- GitLab CI/CD pipeline configuration reference
- GitLab CI/CD include examples
- Introduction to CI/CD with GitLab
- Getting started with GitLab CI/CD
- How to enable or disable GitLab CI/CD
- Using SSH keys with GitLab CI/CD
- Migrating from CircleCI
- Migrating from Jenkins
- Auto DevOps
- Getting started with Auto DevOps
- Requirements for Auto DevOps
- Customizing Auto DevOps
- Stages of Auto DevOps
- Upgrading PostgreSQL for Auto DevOps
- Cache dependencies in GitLab CI/CD
- GitLab ChatOps
- Cloud deployment
- Docker integration
- Building Docker images with GitLab CI/CD
- Using Docker images
- Building images with kaniko and GitLab CI/CD
- GitLab CI/CD environment variables
- Predefined environment variables reference
- Where variables can be used
- Deprecated GitLab CI/CD variables
- Environments and deployments
- Protected Environments
- GitLab CI/CD Examples
- Test a Clojure application with GitLab CI/CD
- Using Dpl as deployment tool
- Testing a Phoenix application with GitLab CI/CD
- End-to-end testing with GitLab CI/CD and WebdriverIO
- DevOps and Game Dev with GitLab CI/CD
- Deploy a Spring Boot application to Cloud Foundry with GitLab CI/CD
- How to deploy Maven projects to Artifactory with GitLab CI/CD
- Testing PHP projects
- Running Composer and NPM scripts with deployment via SCP in GitLab CI/CD
- Test and deploy Laravel applications with GitLab CI/CD and Envoy
- Test and deploy a Python application with GitLab CI/CD
- Test and deploy a Ruby application with GitLab CI/CD
- Test and deploy a Scala application to Heroku
- GitLab CI/CD for external repositories
- Using GitLab CI/CD with a Bitbucket Cloud repository
- Using GitLab CI/CD with a GitHub repository
- GitLab Pages
- GitLab Pages
- GitLab Pages domain names, URLs, and baseurls
- Create a GitLab Pages website from scratch
- Custom domains and SSL/TLS Certificates
- GitLab Pages integration with Let's Encrypt
- GitLab Pages Access Control
- Exploring GitLab Pages
- Incremental Rollouts with GitLab CI/CD
- Interactive Web Terminals
- Optimizing GitLab for large repositories
- Metrics Reports
- CI/CD pipelines
- Pipeline Architecture
- Directed Acyclic Graph
- Multi-project pipelines
- Parent-child pipelines
- Pipelines for Merge Requests
- Pipelines for Merged Results
- Merge Trains
- Job artifacts
- Pipeline schedules
- Pipeline settings
- Triggering pipelines through the API
- Review Apps
- Configuring GitLab Runners
- GitLab CI services examples
- Using MySQL
- Using PostgreSQL
- Using Redis
- Troubleshooting CI/CD
- GitLab Package Registry
- GitLab Container Registry
- Dependency Proxy
- GitLab Composer Repository
- GitLab Conan Repository
- GitLab Maven Repository
- GitLab NPM Registry
- GitLab NuGet Repository
- GitLab PyPi Repository
- API Docs
- API resources
- .gitignore API
- GitLab CI YMLs API
- Group and project access requests API
- Appearance API
- Applications API
- Audit Events API
- Avatar API
- Award Emoji API
- Project badges API
- Group badges API
- Branches API
- Broadcast Messages API
- Project clusters API
- Group clusters API
- Instance clusters API
- Commits API
- Container Registry API
- Custom Attributes API
- Dashboard annotations API
- Dependencies API
- Deploy Keys API
- Deployments API
- Discussions API
- Dockerfiles API
- Environments API
- Epics API
- Events
- Feature Flags API
- Feature flag user lists API
- Freeze Periods API
- Geo Nodes API
- Group Activity Analytics API
- Groups API
- Import API
- Issue Boards API
- Group Issue Boards API
- Issues API
- Epic Issues API
- Issues Statistics API
- Jobs API
- Keys API
- Labels API
- Group Labels API
- License
- Licenses API
- Issue links API
- Epic Links API
- Managed Licenses API
- Markdown API
- Group and project members API
- Merge request approvals API
- Merge requests API
- Project milestones API
- Group milestones API
- Namespaces API
- Notes API
- Notification settings API
- Packages API
- Pages domains API
- Pipeline schedules API
- Pipeline triggers API
- Pipelines API
- Project Aliases API
- Project import/export API
- Project repository storage moves API
- Project statistics API
- Project templates API
- Projects API
- Protected branches API
- Protected tags API
- Releases API
- Release links API
- Repositories API
- Repository files API
- Repository submodules API
- Resource label events API
- Resource milestone events API
- Resource weight events API
- Runners API
- SCIM API
- Search API
- Services API
- Application settings API
- Sidekiq Metrics API
- Snippets API
- Project snippets
- Application statistics API
- Suggest Changes API
- System hooks API
- Tags API
- Todos API
- Users API
- Project-level Variables API
- Group-level Variables API
- Version API
- Vulnerabilities API
- Vulnerability Findings API
- Wikis API
- GraphQL API
- Getting started with GitLab GraphQL API
- GraphQL API Resources
- API V3 to API V4
- Validate the .gitlab-ci.yml (API)
- User Docs
- Abuse reports
- User account
- Active sessions
- Deleting a User account
- Permissions
- Personal access tokens
- Profile preferences
- Threads
- GitLab and SSH keys
- GitLab integrations
- Git
- GitLab.com settings
- Infrastructure as code with Terraform and GitLab
- GitLab keyboard shortcuts
- GitLab Markdown
- AsciiDoc
- GitLab Notification Emails
- GitLab Quick Actions
- Autocomplete characters
- Reserved project and group names
- Search through GitLab
- Advanced Global Search
- Advanced Syntax Search
- Time Tracking
- GitLab To-Do List
- Administrator Docs
- Reference architectures
- Reference architecture: up to 1,000 users
- Reference architecture: up to 2,000 users
- Reference architecture: up to 3,000 users
- Reference architecture: up to 5,000 users
- Reference architecture: up to 10,000 users
- Reference architecture: up to 25,000 users
- Reference architecture: up to 50,000 users
- Troubleshooting a reference architecture set up
- Working with the bundled Consul service
- Configuring PostgreSQL for scaling
- Configuring GitLab application (Rails)
- Load Balancer for multi-node GitLab
- Configuring a Monitoring node for Scaling and High Availability
- NFS
- Working with the bundled PgBouncer service
- Configuring Redis for scaling
- Configuring Sidekiq
- Admin Area settings
- Continuous Integration and Deployment Admin settings
- Custom instance-level project templates
- Diff limits administration
- Enable and disable GitLab features deployed behind feature flags
- Geo nodes Admin Area
- GitLab Pages administration
- Health Check
- Job logs
- Labels administration
- Log system
- PlantUML & GitLab
- Repository checks
- Repository storage paths
- Repository storage types
- Account and limit settings
- Service templates
- System hooks
- Changing your time zone
- Uploads administration
- Abuse reports
- Activating and deactivating users
- Audit Events
- Blocking and unblocking users
- Broadcast Messages
- Elasticsearch integration
- Gitaly
- Gitaly Cluster
- Gitaly reference
- Monitoring GitLab
- Monitoring GitLab with Prometheus
- Performance Bar
- Usage statistics
- Object Storage
- Performing Operations in GitLab
- Cleaning up stale Redis sessions
- Fast lookup of authorized SSH keys in the database
- Filesystem Performance Benchmarking
- Moving repositories managed by GitLab
- Run multiple Sidekiq processes
- Sidekiq MemoryKiller
- Switching to Puma
- Understanding Unicorn and unicorn-worker-killer
- User lookup via OpenSSH's AuthorizedPrincipalsCommand
- GitLab Package Registry administration
- GitLab Container Registry administration
- Replication (Geo)
- Geo database replication
- Geo with external PostgreSQL instances
- Geo configuration
- Using a Geo Server
- Updating the Geo nodes
- Geo with Object storage
- Docker Registry for a secondary node
- Geo for multiple nodes
- Geo security review (Q&A)
- Location-aware Git remote URL with AWS Route53
- Tuning Geo
- Removing secondary Geo nodes
- Geo data types support
- Geo Frequently Asked Questions
- Geo Troubleshooting
- Geo validation tests
- Disaster Recovery (Geo)
- Disaster recovery for planned failover
- Bring a demoted primary node back online
- Automatic background verification
- Rake tasks
- Back up and restore GitLab
- Clean up
- Namespaces
- Maintenance Rake tasks
- Geo Rake Tasks
- GitHub import
- Import bare repositories
- Integrity check Rake task
- LDAP Rake tasks
- Listing repository directories
- Praefect Rake tasks
- Project import/export administration
- Repository storage Rake tasks
- Generate sample Prometheus data
- Uploads migrate Rake tasks
- Uploads sanitize Rake tasks
- User management
- Webhooks administration
- X.509 signatures
- Server hooks
- Static objects external storage
- Updating GitLab
- GitLab release and maintenance policy
- Security
- Password Storage
- Custom password length limits
- Restrict allowed SSH key technologies and minimum length
- Rate limits
- Webhooks and insecure internal web services
- Information exclusivity
- How to reset your root password
- How to unlock a locked user from the command line
- User File Uploads
- How we manage the TLS protocol CRIME vulnerability
- User email confirmation at sign-up
- Security of running jobs
- Proxying assets
- CI/CD Environment Variables
- Contributor and Development Docs
- Contribute to GitLab
- Community members & roles
- Implement design & UI elements
- Issues workflow
- Merge requests workflow
- Code Review Guidelines
- Style guides
- GitLab Architecture Overview
- CI/CD development documentation
- Database guides
- Database Review Guidelines
- Database Review Guidelines
- Migration Style Guide
- What requires downtime?
- Understanding EXPLAIN plans
- Rake tasks for developers
- Mass inserting Rails models
- GitLab Documentation guidelines
- Documentation Style Guide
- Documentation structure and template
- Documentation process
- Documentation site architecture
- Global navigation
- GitLab Docs monthly release process
- Telemetry Guide
- Usage Ping Guide
- Snowplow Guide
- Experiment Guide
- Feature flags in development of GitLab
- Feature flags process
- Developing with feature flags
- Feature flag controls
- Document features deployed behind feature flags
- Frontend Development Guidelines
- Accessibility & Readability
- Ajax
- Architecture
- Axios
- Design Patterns
- Frontend Development Process
- DropLab
- Emojis
- Filter
- Frontend FAQ
- GraphQL
- Icons and SVG Illustrations
- InputSetter
- Performance
- Principles
- Security
- Tooling
- Vuex
- Vue
- Geo (development)
- Geo self-service framework (alpha)
- Gitaly developers guide
- GitLab development style guides
- API style guide
- Go standards and style guidelines
- GraphQL API style guide
- Guidelines for shell commands in the GitLab codebase
- HTML style guide
- JavaScript style guide
- Migration Style Guide
- Newlines style guide
- Python Development Guidelines
- SCSS style guide
- Shell scripting standards and style guidelines
- Sidekiq debugging
- Sidekiq Style Guide
- SQL Query Guidelines
- Vue.js style guide
- Instrumenting Ruby code
- Testing standards and style guidelines
- Flaky tests
- Frontend testing standards and style guidelines
- GitLab tests in the Continuous Integration (CI) context
- Review Apps
- Smoke Tests
- Testing best practices
- Testing levels
- Testing Rails migrations at GitLab
- Testing Rake tasks
- End-to-end Testing
- Beginner's guide to writing end-to-end tests
- End-to-end testing Best Practices
- Dynamic Element Validation
- Flows in GitLab QA
- Page objects in GitLab QA
- Resource class in GitLab QA
- Style guide for writing end-to-end tests
- Testing with feature flags
- Translate GitLab to your language
- Internationalization for GitLab
- Translating GitLab
- Proofread Translations
- Merging translations from CrowdIn
- Value Stream Analytics development guide
- GitLab subscription
- Activate GitLab EE with a license