Skip to content

G
gitlab-ce
Commit c47f909f authored by Marcel Amirault's avatar Marcel Amirault Committed by Evan Read
Browse files
Options

Change usage of CI variables terminology 

We should talk about CI/CD variables, not environment
variables, when talking about variables used in CI/CD
parent 91747f85
Show whitespace changes
Inline Side-by-side
Showing with 58 additions and 58 deletions
doc/topics/autodevops/customize.md
View file @ c47f909f
......@@ -17,7 +17,7 @@ staging and canary deployments,
## Custom buildpacks
If the automatic buildpack detection fails for your project, or if you want to
use a custom buildpack, you can override the buildpack using a project variable
use a custom buildpack, you can override the buildpack using a project CI/CD variable
or a `.buildpacks` file in your project:
- **Project variable** - Create a project variable `BUILDPACK_URL` with the URL
......@@ -43,7 +43,7 @@ can't use the `.buildpacks` file. The buildpack
in the backend to parse the `.buildpacks` file, does not provide the necessary commands
`bin/test-compile` and `bin/test`.
If your goal is to use only a single custom buildpack, you should provide the project variable
If your goal is to use only a single custom buildpack, you should provide the project CI/CD variable
`BUILDPACK_URL` instead.
## Custom `Dockerfile`
......@@ -55,13 +55,13 @@ builds a Docker image based on the Dockerfile, rather than using buildpacks.
This can be much faster and result in smaller images, especially if your
Dockerfile is based on [Alpine](https://hub.docker.com/_/alpine/).
If you set the `DOCKERFILE_PATH` CI variable, Auto Build looks for a Dockerfile there
If you set the `DOCKERFILE_PATH` CI/CD variable, Auto Build looks for a Dockerfile there
instead.
## Passing arguments to `docker build`
Arguments can be passed to the `docker build` command using the
`AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGS` project variable. For example, to build a
`AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGS` project CI/CD variable. For example, to build a
Docker image based on based on the `ruby:alpine` instead of the default `ruby:latest`:
1. Set `AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGS` to `--build-arg=RUBY_VERSION=alpine`.
......@@ -93,12 +93,12 @@ You can extend and manage your Auto DevOps configuration with GitLab APIs:
- [Editing groups](../../api/groups.md#update-group).
- [Editing projects](../../api/projects.md#edit-project).
## Forward CI variables to the build environment
## Forward CI/CD variables to the build environment
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/25514) in GitLab 12.3, but available in versions 11.9 and above.
CI variables can be forwarded into the build environment using the
`AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES` CI variable.
CI/CD variables can be forwarded into the build environment using the
`AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES` CI/CD variable.
The forwarded variables should be specified by name in a comma-separated
list. For example, to forward the variables `CI_COMMIT_SHA` and
`CI_ENVIRONMENT_NAME`, set `AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES`
......@@ -130,7 +130,7 @@ feature to use the `--secret` flag.
Auto DevOps uses [Helm](https://helm.sh/) to deploy your application to Kubernetes.
You can override the Helm chart used by bundling up a chart into your project
repository or by specifying a project variable:
repository or by specifying a project CI/CD variable:
- **Bundled chart** - If your project has a `./chart` directory with a `Chart.yaml`
file in it, Auto DevOps detects the chart and uses it instead of the
......@@ -151,17 +151,17 @@ You can override the default values in the `values.yaml` file in the
- Adding a file named `.gitlab/auto-deploy-values.yaml` to your repository, which is
automatically used, if found.
- Adding a file with a different name or path to the repository, and setting the
`HELM_UPGRADE_VALUES_FILE` [environment variable](#environment-variables) with
`HELM_UPGRADE_VALUES_FILE` [CI/CD variable](#cicd-variables) with
the path and name.
NOTE:
For GitLab 12.5 and earlier, use the `HELM_UPGRADE_EXTRA_ARGS` environment variable
For GitLab 12.5 and earlier, use the `HELM_UPGRADE_EXTRA_ARGS` variable
to override the default chart values by setting `HELM_UPGRADE_EXTRA_ARGS` to `--values <my-values.yaml>`.
## Customize the `helm upgrade` command
You can customize the `helm upgrade` command used in the [auto-deploy-image](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image)
by passing options to the command with the `HELM_UPGRADE_EXTRA_ARGS` variable.
by passing options to the command with the `HELM_UPGRADE_EXTRA_ARGS` CI/CD variable.
For example, set the value of `HELM_UPGRADE_EXTRA_ARGS` to `--no-hooks` to disable
pre-upgrade and post-upgrade hooks when the command is executed.
......@@ -170,7 +170,7 @@ list of options.
## Custom Helm chart per environment
You can specify the use of a custom Helm chart per environment by scoping the environment variable
You can specify the use of a custom Helm chart per environment by scoping the CI/CD variable
to the desired environment. See [Limiting environment scopes of variables](../../ci/variables/README.md#limit-the-environment-scopes-of-cicd-variables).
## Customizing `.gitlab-ci.yml`
......@@ -260,7 +260,7 @@ the [GitLab 12.10 based templates](https://gitlab.com/gitlab-org/auto-devops-v12
To support applications requiring a database,
[PostgreSQL](https://www.postgresql.org/) is provisioned by default. The credentials to access
the database are preconfigured, but can be customized by setting the associated
[variables](#environment-variables). You can use these credentials to define a `DATABASE_URL`:
[CI/CD variables](#cicd-variables). You can use these credentials to define a `DATABASE_URL`:
```yaml
postgres://user:password@postgres-host:postgres-port/postgres-database
......@@ -269,7 +269,7 @@ postgres://user:password@postgres-host:postgres-port/postgres-database
### Upgrading PostgresSQL
WARNING:
The variable `AUTO_DEVOPS_POSTGRES_CHANNEL` that controls default provisioned
The CI/CD variable `AUTO_DEVOPS_POSTGRES_CHANNEL` that controls default provisioned
PostgreSQL was changed to `2` in [GitLab 13.0](https://gitlab.com/gitlab-org/gitlab/-/issues/210499).
To keep using the old PostgreSQL, set the `AUTO_DEVOPS_POSTGRES_CHANNEL` variable to
`1`.
......@@ -290,17 +290,17 @@ production environments, for some use cases, it may not be sufficiently secure o
resilient, and you may want to use an external managed provider (such as
AWS Relational Database Service) for PostgreSQL.
You must define environment-scoped variables for `POSTGRES_ENABLED` and
You must define environment-scoped CI/CD variables for `POSTGRES_ENABLED` and
`DATABASE_URL` in your project's CI/CD settings:
1. Disable the built-in PostgreSQL installation for the required environments using
scoped [environment variables](../../ci/environments/index.md#scoping-environments-with-specs).
environment-scoped [CI/CD variables](../../ci/environments/index.md#scoping-environments-with-specs).
For this use case, it's likely that only `production` must be added to this
list. The built-in PostgreSQL setup for Review Apps and staging is sufficient.
![Auto Metrics](img/disable_postgres.png)
1. Define the `DATABASE_URL` CI variable as a scoped environment variable that is
1. Define the `DATABASE_URL` variable as an environment-scoped variable that is
available to your application. This should be a URL in the following format:
```yaml
......@@ -310,7 +310,7 @@ You must define environment-scoped variables for `POSTGRES_ENABLED` and
You must ensure that your Kubernetes cluster has network access to wherever
PostgreSQL is hosted.
## Environment variables
## CI/CD variables
The following variables can be used for setting up the Auto DevOps domain,
providing a custom Helm chart, or scaling your application. PostgreSQL can
......@@ -318,10 +318,10 @@ also be customized, and you can use a [custom buildpack](#custom-buildpacks).
### Build and deployment
The following table lists variables related to building and deploying
The following table lists CI/CD variables related to building and deploying
applications.
| **Variable** | **Description** |
| **CI/CD Variable** | **Description** |
|-----------------------------------------|------------------------------------|
| `ADDITIONAL_HOSTS` | Fully qualified domain names specified as a comma-separated list that are added to the Ingress hosts. |
| `<ENVIRONMENT>_ADDITIONAL_HOSTS` | For a specific environment, the fully qualified domain names specified as a comma-separated list that are added to the Ingress hosts. This takes precedence over `ADDITIONAL_HOSTS`. |
......@@ -329,7 +329,7 @@ applications.
| `AUTO_DEVOPS_BUILD_IMAGE_CNB_ENABLED` | When set to a non-empty value and no `Dockerfile` is present, Auto Build builds your application using Cloud Native Buildpacks instead of Herokuish. [More details](stages.md#auto-build-using-cloud-native-buildpacks-beta). |
| `AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDER` | The builder used when building with Cloud Native Buildpacks. The default builder is `heroku/buildpacks:18`. [More details](stages.md#auto-build-using-cloud-native-buildpacks-beta). |
| `AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGS` | Extra arguments to be passed to the `docker build` command. Note that using quotes doesn't prevent word splitting. [More details](#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_BUILD_IMAGE_FORWARDED_CI_VARIABLES` | A [comma-separated list of CI/CD variable names](#forward-cicd-variables-to-the-build-environment) to be forwarded to the build environment (the buildpack builder or `docker build`). |
| `AUTO_DEVOPS_CHART` | Helm Chart used to deploy your apps. Defaults to the one [provided by GitLab](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image/-/tree/master/assets/auto-deploy-app). |
| `AUTO_DEVOPS_CHART_REPOSITORY` | Helm Chart repository used to search for charts. Defaults to `https://charts.gitlab.io`. |
| `AUTO_DEVOPS_CHART_REPOSITORY_NAME` | From GitLab 11.11, used to set the name of the Helm repository. Defaults to `gitlab`. |
......@@ -367,9 +367,9 @@ Auto DevOps can undo your changes.
### Database
The following table lists variables related to the database.
The following table lists CI/CD variables related to the database.
| **Variable** | **Description** |
| **CI/CD Variable** | **Description** |
|-----------------------------------------|------------------------------------|
| `DB_INITIALIZE` | From GitLab 11.4, used to specify the command to run to initialize the application's PostgreSQL database. Runs inside the application pod. |
| `DB_MIGRATE` | From GitLab 11.4, used to specify the command to run to migrate the application's PostgreSQL database. Runs inside the application pod. |
......@@ -383,7 +383,7 @@ The following table lists variables related to the database.
The following table lists variables used to disable jobs.
| **Job Name** | **Variable** | **GitLab version** | **Description** |
| **Job Name** | **CI/CDVariable** | **GitLab version** | **Description** |
|----------------------------------------|---------------------------------|-----------------------|-----------------|
| `.fuzz_base` | `COVFUZZ_DISABLED` | [From GitLab 13.2](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/34984) | [Read more](../../user/application_security/coverage_fuzzing/) about how `.fuzz_base` provide capability for your own jobs. If the variable is present, your jobs aren't created. |
| `apifuzzer_fuzz` | `API_FUZZING_DISABLED` | [From GitLab 13.3](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/39135) | If the variable is present, the job isn't created. |
......@@ -433,7 +433,7 @@ The following table lists variables used to disable jobs.
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/49056) in GitLab 11.7.
Some applications need to define secret variables that are accessible by the deployed
application. Auto DevOps detects variables starting with `K8S_SECRET_`, and makes
application. Auto DevOps detects CI/CD variables starting with `K8S_SECRET_`, and makes
these prefixed variables available to the deployed application as environment variables.
To configure your application variables:
......@@ -545,7 +545,7 @@ The normal behavior of Auto DevOps is to use continuous deployment, pushing
automatically to the `production` environment every time a new pipeline is run
on the default branch. However, there are cases where you might want to use a
staging environment, and deploy to production manually. For this scenario, the
`STAGING_ENABLED` environment variable was introduced.
`STAGING_ENABLED` CI/CD variable was introduced.
If you define `STAGING_ENABLED` with a non-empty value, then GitLab automatically deploys the application
to a `staging` environment, and creates a `production_manual` job for
......@@ -584,7 +584,7 @@ are created:
1. `rollout 50%`
1. `rollout 100%`
The percentage is based on the `REPLICAS` variable, and defines the number of
The percentage is based on the `REPLICAS` CI/CD variable, and defines the number of
pods you want to have for your deployment. If the value is `10`, and you run the
`10%` rollout job, there is `1` new pod and `9` old ones.
......@@ -616,8 +616,8 @@ With `INCREMENTAL_ROLLOUT_MODE` set to `manual` and with `STAGING_ENABLED`
![Rollout and staging enabled](img/rollout_staging_enabled.png)
WARNING:
Before GitLab 11.4, the presence of the `INCREMENTAL_ROLLOUT_ENABLED` environment
variable enabled this feature. This configuration is deprecated, and is scheduled to be
Before GitLab 11.4, the presence of the `INCREMENTAL_ROLLOUT_ENABLED` CI/CD variable
enabled this feature. This configuration is deprecated, and is scheduled to be
removed in the future.
### Timed incremental rollout to production **(PREMIUM)**
......@@ -632,7 +632,7 @@ This configuration is based on
Everything behaves the same way, except:
- To enable it, set the `INCREMENTAL_ROLLOUT_MODE` variable to `timed`.
- To enable it, set the `INCREMENTAL_ROLLOUT_MODE` CI/CD variable to `timed`.
- Instead of the standard `production` job, the following jobs are created with
a 5 minute delay between each:
......
doc/topics/autodevops/quick_start_guide.md
View file @ c47f909f
......@@ -234,8 +234,8 @@ takes you to the pod's logs page.
NOTE:
The example shows only one pod hosting the application at the moment, but you can add
more pods by defining the [`REPLICAS` variable](customize.md#environment-variables)
in **Settings > CI/CD > Environment variables**.
more pods by defining the [`REPLICAS` CI/CD variable](customize.md#cicd-variables)
in **Settings > CI / CD > Variables**.
### Work with branches
......@@ -307,7 +307,7 @@ and customized to fit your workflow. Here are some helpful resources for further
1. [Auto DevOps](index.md)
1. [Multiple Kubernetes clusters](index.md#using-multiple-kubernetes-clusters)
1. [Incremental rollout to production](customize.md#incremental-rollout-to-production) **(PREMIUM)**
1. [Disable jobs you don't need with environment variables](customize.md#environment-variables)
1. [Disable jobs you don't need with CI/CD variables](customize.md#cicd-variables)
1. [Use a static IP for your cluster](../../user/clusters/applications.md#using-a-static-ip)
1. [Use your own buildpacks to build your application](customize.md#custom-buildpacks)
1. [Prometheus monitoring](../../user/project/integrations/prometheus.md)
doc/topics/autodevops/requirements.md
View file @ c47f909f
......@@ -109,8 +109,8 @@ After all requirements are met, you can [enable Auto DevOps](index.md#enablingdi
You can choose to target [AWS ECS](../../ci/cloud_deployment/index.md) as a deployment platform instead of using Kubernetes.
To get started on Auto DevOps to AWS ECS, you must add a specific Environment
Variable. To do so, follow these steps:
To get started on Auto DevOps to AWS ECS, you must add a specific CI/CD variable.
To do so, follow these steps:
1. In your project, go to **Settings > CI / CD** and expand the **Variables**
section.
......@@ -121,7 +121,7 @@ Variable. To do so, follow these steps:
- `ECS` if you're not enforcing any launch type check when deploying to ECS.
When you trigger a pipeline, if you have Auto DevOps enabled and if you have correctly
[entered AWS credentials as environment variables](../../ci/cloud_deployment/index.md#deploy-your-application-to-the-aws-elastic-container-service-ecs),
[entered AWS credentials as variables](../../ci/cloud_deployment/index.md#deploy-your-application-to-the-aws-elastic-container-service-ecs),
your application is deployed to AWS ECS.
[GitLab Managed Apps](../../user/clusters/applications.md) are not available when deploying to AWS ECS.
......@@ -145,7 +145,7 @@ own pipeline, as the override stops working when the name changes.
You can target [AWS EC2](../../ci/cloud_deployment/index.md)
as a deployment platform instead of Kubernetes. To use Auto DevOps with AWS EC2, you must add a
specific environment variable.
specific CI/CD variable.
For more details, see [Custom build job for Auto DevOps](../../ci/cloud_deployment/index.md#custom-build-job-for-auto-devops)
for deployments to AWS EC2.
doc/topics/autodevops/stages.md
View file @ c47f909f
......@@ -53,7 +53,7 @@ For the requirements of other languages and frameworks, read the
NOTE:
If Auto Build fails despite the project meeting the buildpack requirements, set
a project variable `TRACE=true` to enable verbose logging, which may help you
a project CI/CD variable `TRACE=true` to enable verbose logging, which may help you
troubleshoot.
### Auto Build using Cloud Native Buildpacks (beta)
......@@ -62,9 +62,9 @@ troubleshoot.
Auto Build supports building your application using [Cloud Native Buildpacks](https://buildpacks.io)
through the [`pack` command](https://github.com/buildpacks/pack). To use Cloud Native Buildpacks,
set the CI variable `AUTO_DEVOPS_BUILD_IMAGE_CNB_ENABLED` to a non-empty
set the CI/CD variable `AUTO_DEVOPS_BUILD_IMAGE_CNB_ENABLED` to a non-empty
value. The default builder is `heroku/buildpacks:18` but a different builder
can be selected using the CI variable `AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDER`.
can be selected using the CI/CD variable `AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDER`.
Cloud Native Buildpacks (CNBs) are an evolution of Heroku buildpacks, and
GitLab expects them to eventually supersede Herokuish-based builds within Auto DevOps. For more
......@@ -286,7 +286,7 @@ see the documentation.
### Overriding the DAST target
To use a custom target instead of the auto-deployed review apps,
set a `DAST_WEBSITE` environment variable to the URL for DAST to scan.
set a `DAST_WEBSITE` CI/CD variable to the URL for DAST to scan.
WARNING:
If [DAST Full Scan](../../user/application_security/dast/index.md#full-scan) is
......@@ -299,10 +299,10 @@ data loss or corruption.
You can disable DAST:
- On all branches by setting the `DAST_DISABLED` environment variable to `"true"`.
- On all branches by setting the `DAST_DISABLED` CI/CD variable to `"true"`.
- Only on the default branch by setting the `DAST_DISABLED_FOR_DEFAULT_BRANCH`
environment variable to `"true"`.
- Only on feature branches by setting `REVIEW_DISABLED` environment variable to
variable to `"true"`.
- Only on feature branches by setting `REVIEW_DISABLED` variable to
`"true"`. This also disables the Review App.
## Auto Browser Performance Testing **(PREMIUM)**
......@@ -338,7 +338,7 @@ uploads the report as an artifact.
Some initial setup is required. A [k6](https://k6.io/) test needs to be
written that's tailored to your specific application. The test also needs to be
configured so it can pick up the environment's dynamic URL via an environment variable.
configured so it can pick up the environment's dynamic URL via a CI/CD variable.
Any load performance test result differences between the source and target branches are also
[shown in the merge request widget](../../user/project/merge_requests/load_performance_testing.md).
......@@ -358,7 +358,7 @@ default, but the
[Auto DevOps template](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml)
contains job definitions for these tasks if you want to enable them.
You can use [environment variables](customize.md#environment-variables) to automatically
You can use [CI/CD variables](customize.md#cicd-variables) to automatically
scale your pod replicas, and to apply custom arguments to the Auto DevOps `helm upgrade`
commands. This is an easy way to
[customize the Auto Deploy Helm chart](customize.md#custom-helm-chart).
......@@ -442,7 +442,7 @@ On GitLab 12.9 and 12.10, opting into
`AUTO_DEVOPS_POSTGRES_CHANNEL` version `2` deletes the version `1` PostgreSQL
database. Follow the [guide to upgrading PostgreSQL](upgrading_postgresql.md)
to back up and restore your database before opting into version `2` (On
GitLab 13.0, an additional variable is required to trigger the database
GitLab 13.0, an additional CI/CD variable is required to trigger the database
deletion).
### Migrations
......@@ -450,7 +450,7 @@ deletion).
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/21955) in GitLab 11.4
You can configure database initialization and migrations for PostgreSQL to run
within the application pod by setting the project variables `DB_INITIALIZE` and
within the application pod by setting the project CI/CD variables `DB_INITIALIZE` and
`DB_MIGRATE` respectively.
If present, `DB_INITIALIZE` is run as a shell command within an application pod
......@@ -502,7 +502,7 @@ access to a Redis instance. Auto DevOps doesn't deploy this instance for you, so
you must:
- Maintain your own Redis instance.
- Set a CI variable `K8S_SECRET_REDIS_URL`, which is the URL of this instance,
- Set a CI/CD variable `K8S_SECRET_REDIS_URL`, which is the URL of this instance,
to ensure it's passed into your deployments.
After configuring your worker to respond to health checks, run a Sidekiq
......@@ -688,5 +688,5 @@ You can follow the [code intelligence epic](https://gitlab.com/groups/gitlab-org
for updates.
This stage is enabled by default. You can disable it by adding the
`CODE_INTELLIGENCE_DISABLED` environment variable. Read more about
`CODE_INTELLIGENCE_DISABLED` CI/CD variable. Read more about
[disabling Auto DevOps jobs](../../topics/autodevops/customize.md#disable-jobs).
doc/topics/autodevops/upgrading_auto_deploy_dependencies.md
View file @ c47f909f
......@@ -114,7 +114,7 @@ If your Auto DevOps project has an active environment that was deployed with the
job saves a backup for 1 week in a job artifact called `helm-2-release-backups`.
The backup is in a Kubernetes manifest file that can be restored using
`kubectl apply -f $backup`.
1. Remove the `MIGRATE_HELM_2TO3` variable.
1. Remove the `MIGRATE_HELM_2TO3` CI/CD variable.
#### In-Cluster PostgreSQL Channel 2
......@@ -145,11 +145,11 @@ steps to upgrade to v2:
them to `production` first to delete the unstable tracks.
1. Verify your project is [using the v2 `auto-deploy-image`](#verify-dependency-versions).
If not, [specify the version](#use-a-specific-version-of-auto-deploy-dependencies).
1. Add an `AUTO_DEVOPS_FORCE_DEPLOY_V2` environment variable with a value of `true`
1. Add an `AUTO_DEVOPS_FORCE_DEPLOY_V2` CI/CD variable with a value of `true`
in the GitLab CI/CD settings.
1. Create a new pipeline and run the `production` job to renew the resource architecture
with the v2 `auto-deploy-app chart`.
1. Remove the `AUTO_DEVOPS_FORCE_DEPLOY_V2` environment variable.
1. Remove the `AUTO_DEVOPS_FORCE_DEPLOY_V2` variable.
### Use a specific version of Auto Deploy dependencies
......@@ -167,7 +167,7 @@ include:
### Ignore warnings and continue deploying
If you are certain that the new chart version is safe to be deployed, you can add
the `AUTO_DEVOPS_FORCE_DEPLOY_V<major-version-number>` [environment variable](customize.md#build-and-deployment)
the `AUTO_DEVOPS_FORCE_DEPLOY_V<major-version-number>` [CI/CD variable](customize.md#build-and-deployment)
to force the deployment to continue.
For example, if you want to deploy the `v2.0.0` chart on a deployment that previously
......
doc/user/application_security/security_dashboard/index.md
View file @ c47f909f
......@@ -175,7 +175,7 @@ lock files. Python projects can have lock files, but GitLab Secure tools don't s
## Security scans using Auto DevOps
When using [Auto DevOps](../../../topics/autodevops/index.md), use
[special environment variables](../../../topics/autodevops/customize.md#environment-variables)
[special environment variables](../../../topics/autodevops/customize.md#cicd-variables)
to configure daily security scans.
<!-- ## Troubleshooting
......
doc/user/clusters/applications.md
View file @ c47f909f
......@@ -372,7 +372,7 @@ For GitLab Runner to function, you _must_ specify the following:
- `runnerRegistrationToken`: The registration token for adding new runners to GitLab.
This must be [retrieved from your GitLab instance](../../ci/runners/README.md).
These values can be specified using [CI variables](../../ci/variables/README.md):
These values can be specified using [CI/CD variables](../../ci/variables/README.md):
- `GITLAB_RUNNER_GITLAB_URL` is used for `gitlabUrl`.
- `GITLAB_RUNNER_REGISTRATION_TOKEN` is used for `runnerRegistrationToken`
......@@ -730,7 +730,7 @@ Set:
- "Redirect URI" to `http://<JupyterHub Host>/hub/oauth_callback`.
- "Scope" to `api read_repository write_repository`.
In addition, the following variables must be specified using [CI variables](../../ci/variables/README.md):
In addition, the following variables must be specified using [CI/CD variables](../../ci/variables/README.md):
- `JUPYTERHUB_PROXY_SECRET_TOKEN` - Secure string used for signing communications
from the hub. Read [`proxy.secretToken`](https://zero-to-jupyterhub.readthedocs.io/en/stable/reference/reference.html#proxy-secrettoken).
......
doc/user/project/clusters/add_eks_clusters.md
View file @ c47f909f
......@@ -326,7 +326,7 @@ If a default Storage Class doesn't already exist and is desired, follow Amazon's
to create one.
Alternatively, disable PostgreSQL by setting the project variable
[`POSTGRES_ENABLED`](../../../topics/autodevops/customize.md#environment-variables) to `false`.
[`POSTGRES_ENABLED`](../../../topics/autodevops/customize.md#cicd-variables) to `false`.
### Deploy the app to EKS
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7