* (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.
@@ -4,8 +4,8 @@ This project implements a GitLab CI/CD template for [GNU Make](https://www.gnu.o
## 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
@@ -83,7 +83,7 @@ It uses the following variable:
### Build Output
The `make-build` job is supposed to build the project. Consequently, it will produce binary/executable artifacts, that should be stored as [job artifacts](https://docs.gitlab.com/ee/ci/yaml/artifacts_reports.html).
The `make-build` job is supposed to build the project. Consequently, it will produce binary/executable artifacts, that should be stored as [job artifacts](https://docs.gitlab.com/ci/yaml/artifacts_reports/).
By default, `build/` is defined as the build output directory. If it is not the case in your project, you'll have to override default as follows:
@@ -106,7 +106,7 @@ If you decide to implement unit tests in this job, here are (optional) requireme
#### Unit Test reports integration
If the unit testing framework you're using is capable of producing JUnit reports, you'll take great benefits from implementing the [GitLab integration](https://docs.gitlab.com/ee/ci/testing/unit_test_reports.html).
If the unit testing framework you're using is capable of producing JUnit reports, you'll take great benefits from implementing the [GitLab integration](https://docs.gitlab.com/ci/testing/unit_test_reports/).
Altough you're free to generate the reports wherever you like, _to-be-continuous_ uses a convention to produce them in `reports/<tool_name>-test.xunit.xml`.
You'll need to declare the reports in your `.gitlab-ci.yaml` as follows:
@@ -123,9 +123,9 @@ make-build:
If the unit testing framework you're using is capable of computing code coverage, you'll take great benefits from implementing one or both of the GitLab integrations:
1.[test coverage results in merge requests](https://docs.gitlab.com/ee/ci/testing/test_coverage_visualization.html)<br/>
_let GitLab capture the global coverage result (percentage) from the output logs by defining a regular expression with the [`coverage` keyword](https://docs.gitlab.com/ee/ci/yaml/index.html#coverage)_
2.[Cobertura XML report](https://docs.gitlab.com/ee/ci/testing/test_coverage_visualization.html) integration<br/>
1.[test coverage results in merge requests](https://docs.gitlab.com/ci/testing/code_coverage/)<br/>
_let GitLab capture the global coverage result (percentage) from the output logs by defining a regular expression with the [`coverage` keyword](https://docs.gitlab.com/ci/yaml/#coverage)_
2.[Cobertura XML report](https://docs.gitlab.com/ci/testing/code_coverage/) integration<br/>
_provide GitLab with a detailed Cobertura XML report_<br/>
Altough you're free to generate the reports wherever you like, _to-be-continuous_ uses a convention to produce them in `reports/<tool_name>-coverage.cobertura.xml`
@@ -170,7 +170,7 @@ make-my-lint:
paths:
-"reports/my-lint.*"
# also declare any GitLab supported report if need be