Docs: Update Variable naming
This commit is contained in:
parent
f69f7a6702
commit
6e2570d2d5
Binary file not shown.
Before Width: | Height: | Size: 49 KiB |
Binary file not shown.
After Width: | Height: | Size: 28 KiB |
|
@ -106,10 +106,10 @@ Now, since the steps defined in `.gitlab-ci.yml` require credentials to login
|
|||
to CF, you'll need to add your CF credentials as [environment
|
||||
variables](../../variables/README.md#predefined-variables-environment-variables)
|
||||
on GitLab CI/CD. To set the environment variables, navigate to your project's
|
||||
**Settings > CI/CD** and expand **Secret Variables**. Name the variables
|
||||
**Settings > CI/CD** and expand **Variables**. Name the variables
|
||||
`CF_USERNAME` and `CF_PASSWORD` and set them to the correct values.
|
||||
|
||||
![Secret Variable Settings in GitLab](img/cloud_foundry_secret_variables.png)
|
||||
![Variable Settings in GitLab](img/cloud_foundry_variables.png)
|
||||
|
||||
Once set up, GitLab CI/CD will deploy your app to CF at every push to your
|
||||
repository's deafult branch. To see the build logs or watch your builds running
|
||||
|
|
|
@ -101,12 +101,12 @@ production:
|
|||
We created two deploy jobs that are executed on different events:
|
||||
|
||||
1. `staging` is executed for all commits that were pushed to `master` branch,
|
||||
2. `production` is executed for all pushed tags.
|
||||
1. `production` is executed for all pushed tags.
|
||||
|
||||
We also use two secure variables:
|
||||
|
||||
1. `HEROKU_STAGING_API_KEY` - Heroku API key used to deploy staging app,
|
||||
2. `HEROKU_PRODUCTION_API_KEY` - Heroku API key used to deploy production app.
|
||||
1. `HEROKU_PRODUCTION_API_KEY` - Heroku API key used to deploy production app.
|
||||
|
||||
## Storing API keys
|
||||
|
||||
|
@ -120,7 +120,7 @@ is hidden in the job log.
|
|||
You access added variable by prefixing it's name with `$` (on non-Windows runners)
|
||||
or `%` (for Windows Batch runners):
|
||||
|
||||
1. `$SECRET_VARIABLE` - use it for non-Windows runners
|
||||
2. `%SECRET_VARIABLE%` - use it for Windows Batch runners
|
||||
1. `$VARIABLE` - use it for non-Windows runners
|
||||
1. `%VARIABLE%` - use it for Windows Batch runners
|
||||
|
||||
Read more about the [CI variables](../../variables/README.md).
|
||||
|
|
|
@ -43,7 +43,7 @@ All these operations will put all files into a `build` folder, which is ready to
|
|||
|
||||
You have multiple options: rsync, scp, sftp and so on. For now, we will use scp.
|
||||
|
||||
To make this work, you need to add a GitLab Secret Variable (accessible on _gitlab.example/your-project-name/variables_). That variable will be called `STAGING_PRIVATE_KEY` and it's the **private** ssh key of your server.
|
||||
To make this work, you need to add a GitLab CI/CD Variable (accessible on _gitlab.example/your-project-name/variables_). That variable will be called `STAGING_PRIVATE_KEY` and it's the **private** ssh key of your server.
|
||||
|
||||
### Security tip
|
||||
|
||||
|
|
|
@ -418,7 +418,7 @@ fully understand [IAM Best Practices in AWS](http://docs.aws.amazon.com/IAM/late
|
|||
1. Click the **Access Keys** section and **Create New Access Key**. Create the key and keep the id and secret around, you'll need them later
|
||||
![AWS Access Key Config](img/aws_config_window.png)
|
||||
1. Go to your GitLab project, click **Settings > CI/CD** on the left sidebar
|
||||
1. Expand the **Secret Variables** section
|
||||
1. Expand the **Variables** section
|
||||
![GitLab Secret Config](img/gitlab_config.png)
|
||||
1. Add a key named `AWS_KEY_ID` and copy the key id from Step 2 into the **Value** textbox
|
||||
1. Add a key named `AWS_KEY_SECRET` and copy the key secret from Step 2 into the **Value** textbox
|
||||
|
|
Binary file not shown.
Before Width: | Height: | Size: 95 KiB |
Binary file not shown.
After Width: | Height: | Size: 27 KiB |
|
@ -120,12 +120,12 @@ Now, let's add it to your GitLab project as a [variable](../../variables/README.
|
|||
Variables are user-defined variables and are stored out of `.gitlab-ci.yml`, for security purposes.
|
||||
They can be added per project by navigating to the project's **Settings** > **CI/CD**.
|
||||
|
||||
![variables page](img/secret_variables_page.png)
|
||||
|
||||
To the field **KEY**, add the name `SSH_PRIVATE_KEY`, and to the **VALUE** field, paste the private key you've copied earlier.
|
||||
We'll use this variable in the `.gitlab-ci.yml` later, to easily connect to our remote server as the deployer user without entering its password.
|
||||
|
||||
We also need to add the public key to **Project** > **Settings** > **Repository** as [Deploy Keys](../../../ssh/README.md#deploy-keys), which gives us the ability to access our repository from the server through [SSH protocol](../../../gitlab-basics/command-line-commands.md#start-working-on-your-project).
|
||||
![variables page](img/variables_page.png)
|
||||
|
||||
We also need to add the public key to **Project** > **Settings** > **Repository** as a [Deploy Key](../../../ssh/README.md#deploy-keys), which gives us the ability to access our repository from the server through [SSH protocol](../../../gitlab-basics/command-line-commands.md#start-working-on-your-project).
|
||||
|
||||
|
||||
```bash
|
||||
|
@ -135,10 +135,10 @@ We also need to add the public key to **Project** > **Settings** > **Repository*
|
|||
cat ~/.ssh/id_rsa.pub
|
||||
```
|
||||
|
||||
![deploy keys page](img/deploy_keys_page.png)
|
||||
|
||||
To the field **Title**, add any name you want, and paste the public key into the **Key** field.
|
||||
|
||||
![deploy keys page](img/deploy_keys_page.png)
|
||||
|
||||
Now, let's clone our repository on the server just to make sure the `deployer` user has access to the repository.
|
||||
|
||||
```bash
|
||||
|
|
|
@ -409,7 +409,7 @@ You can use the following fake tokens as examples.
|
|||
| Personal access token | `n671WNGecHugsdEDPsyo` |
|
||||
| Application ID | `2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6` |
|
||||
| Application secret | `04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df` |
|
||||
| Secret CI variable | `Li8j-mLUVA3eZYjPfd_H` |
|
||||
| CI/CD variable | `Li8j-mLUVA3eZYjPfd_H` |
|
||||
| Specific Runner token | `yrnZW46BrtBFqM7xDzE7dddd` |
|
||||
| Shared Runner token | `6Vk7ZsosqQyfreAxXTZr` |
|
||||
| Trigger token | `be20d8dcc028677c931e04f3871a9b` |
|
||||
|
|
|
@ -586,7 +586,7 @@ repo or by specifying a project variable:
|
|||
file in it, Auto DevOps will detect the chart and use it instead of the [default
|
||||
one](https://gitlab.com/charts/auto-deploy-app).
|
||||
This can be a great way to control exactly how your application is deployed.
|
||||
- **Project variable** - Create a [project variable](../../ci/variables/README.md#secret-variables)
|
||||
- **Project variable** - Create a [project variable](../../ci/variables/README.md#variables)
|
||||
`AUTO_DEVOPS_CHART` with the URL of a custom chart to use.
|
||||
|
||||
### Customizing `.gitlab-ci.yml`
|
||||
|
@ -660,7 +660,7 @@ also be customized, and you can easily use a [custom buildpack](#custom-buildpac
|
|||
|
||||
TIP: **Tip:**
|
||||
Set up the replica variables using a
|
||||
[project variable](../../ci/variables/README.md#secret-variables)
|
||||
[project variable](../../ci/variables/README.md#variables)
|
||||
and scale your application by just redeploying it!
|
||||
|
||||
CAUTION: **Caution:**
|
||||
|
@ -738,7 +738,7 @@ staging environment and deploy to production manually. For this scenario, the
|
|||
`STAGING_ENABLED` environment variable was introduced.
|
||||
|
||||
If `STAGING_ENABLED` is defined in your project (e.g., set `STAGING_ENABLED` to
|
||||
`1` as a secret variable), then the application will be automatically deployed
|
||||
`1` as a CI/CD variable), then the application will be automatically deployed
|
||||
to a `staging` environment, and a `production_manual` job will be created for
|
||||
you when you're ready to manually deploy to production.
|
||||
|
||||
|
@ -751,7 +751,7 @@ A [canary environment](https://docs.gitlab.com/ee/user/project/canary_deployment
|
|||
before any changes are deployed to production.
|
||||
|
||||
If `CANARY_ENABLED` is defined in your project (e.g., set `CANARY_ENABLED` to
|
||||
`1` as a secret variable) then two manual jobs will be created:
|
||||
`1` as a CI/CD variable) then two manual jobs will be created:
|
||||
|
||||
- `canary` which will deploy the application to the canary environment
|
||||
- `production_manual` which is to be used by you when you're ready to manually
|
||||
|
|
Loading…
Reference in New Issue