* (type here the used build & test tools/frameworks)
* [ ] mapped to the `build` stage
*[ ] declare a common `.test-policy` job with rules implementing the [Adaptive Pipeline strategy](https://to-be-continuous.gitlab.io/doc/usage/#test-analysis-jobs-rules) and use in test & SAST jobs
*[ ] unit tests report integration using [JUnit test report](https://docs.gitlab.com/ee/ci/yaml/artifacts_reports.html#artifactsreportsjunit)
*[ ] code coverage computing and [integration](https://docs.gitlab.com/ee/ci/yaml/#coverage)
* must be executed on non-`master`, non-`develop` branches only
* must be associated to the [`environment:action:stop`](https://docs.gitlab.com/ee/ci/yaml/#environmentaction) event
* must be associated to the [`environment:action:stop`](https://docs.gitlab.com/ci/yaml/#environmentaction) event
* (optional) Analysis job(s) (linters, dependency checks, ...) depending on the technologies:
* [ ] mapped to the `test` stage
*[ ] declare a common `.test-policy` job with rules implementing the [Adaptive Pipeline strategy](https://to-be-continuous.gitlab.io/doc/usage/#test-analysis-jobs-rules) and use in test & SAST jobs
*[ ] declare a common `.acceptance-policy` job with rules implementing the [Adaptive Pipeline strategy](https://to-be-continuous.gitlab.io/doc/usage/#test-analysis-jobs-rules) and use in test & SAST jobs
*[ ] tests report integration using [JUnit test report](https://docs.gitlab.com/ee/ci/yaml/artifacts_reports.html#artifactsreportsjunit)
*[ ] tests report integration using [JUnit test report](https://docs.gitlab.com/ci/yaml/artifacts_reports/#artifactsreportsjunit)
* [ ] auto-evaluating the environment url to test based on the possible upstream `$environment_url` variable or via
1. Create an issue describing the bug or enhancement you want to propose (select the right issue template).
2. Make sure the issue has been reviewed and agreed.
3. Create a Merge Request, from your **own** fork (see [forking workflow](https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html) documentation).
3. Create a Merge Request, from your **own** fork (see [forking workflow](https://docs.gitlab.com/user/project/repository/forking_workflow/) documentation).
Don't hesitate to mark your MR as `Draft` as long as you think it's not ready to be reviewed.
When enabled, it deploys the result from upstream build stages to a dedicated and temporary environment.
It is only active for non-production, non-integration branches.
It is a strict equivalent of GitLab's [Review Apps](https://docs.gitlab.com/ee/ci/review_apps/) feature.
It is a strict equivalent of GitLab's [Review Apps](https://docs.gitlab.com/ci/review_apps/) feature.
It also comes with a _cleanup_ job (accessible either from the _environments_ page, or from the pipeline view).
@@ -204,8 +204,8 @@ and [templating](https://helmfile.readthedocs.io/en/latest/#templating). All env
are at your disposal within your `helmfile` templates:
-[deployment context variables](#deployment-context-variables) provided by the CI/CD template,
- any [GitLab CI variable](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html)
- any [custom variable](https://docs.gitlab.com/ee/ci/variables/#for-a-project)
- any [GitLab CI variable](https://docs.gitlab.com/ci/variables/predefined_variables/)
- any [custom variable](https://docs.gitlab.com/ci/variables/#for-a-project)
(ex: ${SECRET_TOKEN} that you have set in your project CI/CD variables)
The deployment context variable `$environment_type` is passed as
@@ -218,7 +218,7 @@ and customize releases per deployment environment type.
The Helmfile template supports two ways of providing your environments url:
* a **static way**: when the environments url can be determined in advance, probably because you're exposing your routes through a DNS you manage,
* a [**dynamic way**](https://docs.gitlab.com/ee/ci/environments/#set-a-dynamic-environment-url): when the url cannot be known before the deployment job is executed.
* a [**dynamic way**](https://docs.gitlab.com/ci/environments/#set-a-dynamic-environment-url): when the url cannot be known before the deployment job is executed.
The **static way** can be implemented simply by setting the appropriate configuration variable(s) depending on the environment (see environments configuration chapters):
@@ -247,7 +247,7 @@ by the template, it will use it as the newly deployed environment url.
### Deployment output variables
Each deployment job produces _output variables_ that are propagated to downstream jobs (using [dotenv artifacts](https://docs.gitlab.com/ee/ci/yaml/artifacts_reports.html#artifactsreportsdotenv)):
Each deployment job produces _output variables_ that are propagated to downstream jobs (using [dotenv artifacts](https://docs.gitlab.com/ci/yaml/artifacts_reports/#artifactsreportsdotenv)):
*`$environment_type`: set to the type of environment (`review`, `integration`, `staging` or `production`),
*`$environment_name`: the application name (see below),
@@ -263,12 +263,12 @@ You may also add and propagate your own custom variables, by pushing them to the
Here are some advices about your **secrets** (variables marked with a :lock:):
1. Manage them as [project or group CI/CD variables](https://docs.gitlab.com/ee/ci/variables/#for-a-project):
*[**masked**](https://docs.gitlab.com/ee/ci/variables/#mask-a-cicd-variable) to prevent them from being inadvertently
1. Manage them as [project or group CI/CD variables](https://docs.gitlab.com/ci/variables/#for-a-project):
*[**masked**](https://docs.gitlab.com/ci/variables/#mask-a-cicd-variable) to prevent them from being inadvertently
displayed in your job logs,
*[**protected**](https://docs.gitlab.com/ee/ci/variables/#protected-cicd-variables) if you want to secure some secrets
*[**protected**](https://docs.gitlab.com/ci/variables/#protected-cicd-variables) if you want to secure some secrets
you don't want everyone in the project to have access to (for instance production secrets).
2. In case a secret contains [characters that prevent it from being masked](https://docs.gitlab.com/ee/ci/variables/#mask-a-cicd-variable),
2. In case a secret contains [characters that prevent it from being masked](https://docs.gitlab.com/ci/variables/#mask-a-cicd-variable),
simply define its value as the [Base64](https://en.wikipedia.org/wiki/Base64) encoded value prefixed with `@b64@`:
it will then be possible to mask it and the template will automatically decode it prior to using it.
3. Don't forget to escape special characters (ex: `$` -> `$$`).
@@ -282,16 +282,16 @@ The Helm template uses some global configuration used throughout all jobs.
| `cli-image` / `HELMFILE_CLI_IMAGE` | The Docker image used to run helmfile <br/>:warning: **set the version required by your Kubernetes server** | `ghcr.io/helmfile/helmfile:latest`<br/>[](https://to-be-continuous.gitlab.io/doc/secu/trivy-HELMFILE_CLI_IMAGE) |
| `path` / `HELMFILE_PATH` | The path to your `helmfile.yaml` | `./helmfile.yaml` |
| `scripts-dir` / `HELMFILE_SCRIPTS_DIR` | The folder where hook scripts are located | `.` _(root project dir)_ |
| `kube-namespace` / `KUBE_NAMESPACE` | The default Kubernetes namespace to use | `"${CI_PROJECT_NAME}-${CI_PROJECT_ID}-${CI_ENVIRONMENT_SLUG}"` ([see GitLab doc](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html)) |
| `KUBE_CONTEXT` | Defines the context to be used in `KUBECONFIG`. When using [GitLab agents with the CI/CD workflow](https://docs.gitlab.com/ee/user/clusters/agent/ci_cd_workflow.html), the value should be like `path/to/agent/project:agent-name`. To use different agents per environment, define an [environment-scoped CI/CD variable](https://docs.gitlab.com/ee/ci/environments/index.html#limit-the-environment-scope-of-a-cicd-variable) for each agent. | _none_ |
| :lock: `HELMFILE_DEFAULT_KUBE_CONFIG` | The default kubeconfig to use (either content or file variable) | `$KUBECONFIG` (thus supports the [GitLab Kubernetes integration](https://docs.gitlab.com/ee/user/project/clusters/index.html) when enabled) |
| `kube-namespace` / `KUBE_NAMESPACE` | The default Kubernetes namespace to use | `"${CI_PROJECT_NAME}-${CI_PROJECT_ID}-${CI_ENVIRONMENT_SLUG}"` ([see GitLab doc](https://docs.gitlab.com/ci/variables/predefined_variables/)) |
| `KUBE_CONTEXT` | Defines the context to be used in `KUBECONFIG`. When using [GitLab agents with the CI/CD workflow](https://docs.gitlab.com/user/clusters/agent/ci_cd_workflow/), the value should be like `path/to/agent/project:agent-name`. To use different agents per environment, define an [environment-scoped CI/CD variable](https://docs.gitlab.com/ci/environments/#limit-the-environment-scope-of-a-cicd-variable) for each agent. | _none_ |
| :lock: `HELMFILE_DEFAULT_KUBE_CONFIG` | The default kubeconfig to use (either content or file variable) | `$KUBECONFIG` (thus supports the [GitLab Kubernetes integration](https://docs.gitlab.com/user/project/clusters/) when enabled) |
| `deploy-args` / `HELMFILE_DEPLOY_ARGS` | The helmfile [command with options](https://helmfile.readthedocs.io/en/latest/#apply) to deploy the application (_without dynamic global parameters such as `helmfile.yaml` path and environment name_) | `apply --wait` |
| `delete-args` / `HELMFILE_DELETE_ARGS` | The helmfile [command with options](https://helmfile.readthedocs.io/en/latest/#destroy) to cleanup the application (_without dynamic global parameters such as `helmfile.yaml` path and environment name_) | `destroy` |
| `base-app-name` / `HELMFILE_BASE_APP_NAME` | Base application name | `$CI_PROJECT_NAME` ([see GitLab doc](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html)) |
| `base-app-name` / `HELMFILE_BASE_APP_NAME` | Base application name | `$CI_PROJECT_NAME` ([see GitLab doc](https://docs.gitlab.com/ci/variables/predefined_variables/)) |
| `image-pull-secret-name` / `HELMFILE_IMAGE_PULL_SECRET_NAME` | Name of the `docker-registry` k8s secret that will be created if the special [GitLab deploy token](https://docs.gitlab.com/ee/user/project/deploy_tokens/#gitlab-deploy-token) is available. | `gitlab-registry` |
| `image-pull-secret-name` / `HELMFILE_IMAGE_PULL_SECRET_NAME` | Name of the `docker-registry` k8s secret that will be created if the special [GitLab deploy token](https://docs.gitlab.com/user/project/deploy_tokens/#gitlab-deploy-token) is available. | `gitlab-registry` |
### Review environments configuration
@@ -403,7 +403,7 @@ In order to be able to communicate with the Vault server, the variant requires t
| :lock: `VAULT_ROLE_ID` | The [AppRole](https://www.vaultproject.io/docs/auth/approle) RoleID | _none_ |
| :lock: `VAULT_SECRET_ID` | The [AppRole](https://www.vaultproject.io/docs/auth/approle) SecretID | _none_ |
By default, the variant will authentifacte using a [JWT ID token](https://docs.gitlab.com/ee/ci/secrets/id_token_authentication.html). To use [AppRole](https://www.vaultproject.io/docs/auth/approle) instead the `VAULT_ROLE_ID` and `VAULT_SECRET_ID` should be defined as secret project variables.
By default, the variant will authentifacte using a [JWT ID token](https://docs.gitlab.com/ci/secrets/id_token_authentication/). To use [AppRole](https://www.vaultproject.io/docs/auth/approle) instead the `VAULT_ROLE_ID` and `VAULT_SECRET_ID` should be defined as secret project variables.
"description":"The default Kubernetes namespace to use. _Leave default if [GitLab Kubernetes integration](https://docs.gitlab.com/ee/user/project/clusters/index.html) is enabled._"
"description":"The default Kubernetes namespace to use. _Leave default if [GitLab Kubernetes integration](https://docs.gitlab.com/user/project/clusters/) is enabled._"
},
{
"name":"HELMFILE_DEFAULT_KUBE_CONFIG",
@@ -66,7 +66,7 @@
},
{
"name":"HELMFILE_IMAGE_PULL_SECRET_NAME",
"description":"Name of the `docker-registry` k8s secret that will be created if the special [GitLab deploy token](https://docs.gitlab.com/ee/user/project/deploy_tokens/#gitlab-deploy-token) is available.",
"description":"Name of the `docker-registry` k8s secret that will be created if the special [GitLab deploy token](https://docs.gitlab.com/user/project/deploy_tokens/#gitlab-deploy-token) is available.",
"default":"gitlab-registry",
"advanced":true
}
@@ -103,7 +103,7 @@
{
"id":"review",
"name":"Review",
"description":"Dynamic review environments for your topic branches (see GitLab [Review Apps](https://docs.gitlab.com/ee/ci/review_apps/))",
"description":"Dynamic review environments for your topic branches (see GitLab [Review Apps](https://docs.gitlab.com/ci/review_apps/))",
