* (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.
@@ -5,8 +5,8 @@ your source code with [Source-to-Image](https://github.com/openshift/source-to-i
## Usage
This template can be used both as a [CI/CD component](https://docs.gitlab.com/ee/ci/components/#use-a-component)
or using the legacy [`include:project`](https://docs.gitlab.com/ee/ci/yaml/index.html#includeproject) syntax.
This template can be used both as a [CI/CD component](https://docs.gitlab.com/ci/components/#use-a-component)
or using the legacy [`include:project`](https://docs.gitlab.com/ci/yaml/#includeproject) syntax.
### Use as a CI/CD component
@@ -115,12 +115,12 @@ If you use **different registries** for snapshot and release images, you shall u
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: `$` -> `$$`).
@@ -141,7 +141,7 @@ It uses the following variable:
| `builder-image` / `S2I_BUILDER_IMAGE` | The S2I [builder image](https://github.com/openshift/source-to-image/blob/master/docs/builder_image.md) used to build your application image | _none_ (required) |
This job produces _output variables_ that are propagated to downstream jobs (using [dotenv artifacts](https://docs.gitlab.com/ee/ci/yaml/artifacts_reports.html#artifactsreportsdotenv)):
This job produces _output variables_ that are propagated to downstream jobs (using [dotenv artifacts](https://docs.gitlab.com/ci/yaml/artifacts_reports/#artifactsreportsdotenv)):
@@ -165,7 +165,7 @@ This job pushes (_promotes_) the built image as the _release_ image using [skope
| `release-extra-tags` / `S2I_RELEASE_EXTRA_TAGS` | Defines extra tags to publish the _release_ image (supports capturing group references from `$S2I_RELEASE_EXTRA_TAGS_PATTERN` - [see below](#using-extra-tags)) | _(none)_ |
| `semrel-release-disabled` / `S2I_SEMREL_RELEASE_DISABLED` | Set to `true` to disable [semantic-release integration](#semantic-release-integration) | _none_ (enabled) |
This job produces _output variables_ that are propagated to downstream jobs (using [dotenv artifacts](https://docs.gitlab.com/ee/ci/yaml/artifacts_reports.html#artifactsreportsdotenv)):
This job produces _output variables_ that are propagated to downstream jobs (using [dotenv artifacts](https://docs.gitlab.com/ci/yaml/artifacts_reports/#artifactsreportsdotenv)):