* (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 to continuously analyse your web
## 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
@@ -64,7 +64,7 @@ In addition to a textual report in the console, this job produces the following
The `$LHCI_RUN_OPTS` variable supports a **late variable expansion mechanism** with the `%{somevar}` syntax.
Therefore if an upstream job in the pipeline deployed your code to a server and propagated the deployed server url
as `$environment_url` variable (through a [dotenv artifact](https://docs.gitlab.com/ee/ci/yaml/artifacts_reports.html#artifactsreportsdotenv)),
as `$environment_url` variable (through a [dotenv artifact](https://docs.gitlab.com/ci/yaml/artifacts_reports/#artifactsreportsdotenv)),
then you can easily run Lighthouse CI against this server, simply by using the `%{environment_url}` syntax in the `$LHCI_RUN_OPTS` variable.
:warning: all _to be continuous_ depoyment templates implement this design. Therefore even purely dynamic environments (such as review
@@ -72,7 +72,7 @@ environments) will automatically be propagated to your Lighthouse CI analysis.
If you're not using your own deployment job, you may:
1. implement the common _to be continuous_ design (i.e. propagate the environment base url as `$environment_url` variable through a [dotenv artifact](https://docs.gitlab.com/ee/ci/yaml/artifacts_reports.html#artifactsreportsdotenv))
1. implement the common _to be continuous_ design (i.e. propagate the environment base url as `$environment_url` variable through a [dotenv artifact](https://docs.gitlab.com/ci/yaml/artifacts_reports/#artifactsreportsdotenv))
2. use any programmatic solution of your choice with a JavaScript-based [configuration file](https://github.com/GoogleChrome/lighthouse-ci/blob/main/docs/configuration.md#configuration-file).
3. explicitly set the `collect.url` option in the `LHCI_RUN_OPTS` variable (hardcoded to a single server),