@@ -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/pipelines/job_artifacts.html#artifactsreportsdotenv)),
as `$environment_url` variable (through a [dotenv artifact](https://docs.gitlab.com/ee/ci/yaml/artifacts_reports.html#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/pipelines/job_artifacts.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/ee/ci/yaml/artifacts_reports.html#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),
