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.
k6 test reports are [integrated to GitLab by generating load performance reports](https://docs.gitlab.com/ee/ci/testing/load_performance_testing.html).
k6 test reports are [integrated to GitLab by generating load performance reports](https://docs.gitlab.com/ci/testing/load_performance_testing/).
This is done using the following CLI options: `--out json=reports/`
@@ -70,7 +70,7 @@ By default, the k6 template tries to auto-evaluate the base URL (i.e. the variab
looking either for a `$environment_url` variable or for an `environment_url.txt` file.
Therefore if an upstream job in the pipeline deployed your code to a server and propagated the deployed server url,
either through a [dotenv](https://docs.gitlab.com/ee/ci/yaml/artifacts_reports.html#artifactsreportsdotenv) variable `$environment_url`
either through a [dotenv](https://docs.gitlab.com/ci/yaml/artifacts_reports/#artifactsreportsdotenv) variable `$environment_url`
or through a basic `environment_url.txt` file, then the k6 test will automatically be run on this server.
:warning: all our deployment templates implement this design. Therefore even purely dynamic environments (such as review