diff options
Diffstat (limited to 'doc/ci/testing')
17 files changed, 231 insertions, 44 deletions
diff --git a/doc/ci/testing/accessibility_testing.md b/doc/ci/testing/accessibility_testing.md index fa57371a7d5..b03e4a23153 100644 --- a/doc/ci/testing/accessibility_testing.md +++ b/doc/ci/testing/accessibility_testing.md @@ -1,13 +1,18 @@ --- stage: Verify -group: Pipeline Insights +group: Pipeline Execution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments --- -# Accessibility testing **(FREE)** +<!--- start_remove The following content will be removed on remove_date: '2024-05-22' --> +# Accessibility testing (deprecated) **(FREE)** > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/25144) in GitLab 12.8. +WARNING: +This feature was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/390424) in GitLab 15.9 +and is planned for removal in 17.0. This change is a breaking change. + If your application offers a web interface, you can use [GitLab CI/CD](../index.md) to determine the accessibility impact of pending code changes. @@ -25,7 +30,7 @@ As of [GitLab 14.5](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/73309) ## Accessibility merge request widget > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/39425) in GitLab 13.0 behind the disabled [feature flag](../../administration/feature_flags.md) `:accessibility_report_view`. -> - [Feature Flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/217372) in GitLab 13.1. +> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/217372) in GitLab 13.1. GitLab displays an **Accessibility Report** in the merge request widget area: @@ -63,7 +68,7 @@ The `a11y` job in your CI/CD pipeline generates these files: file is named `gl-accessibility.json`. In GitLab versions 12.10 and earlier, this file is named [`accessibility.json`](https://gitlab.com/gitlab-org/ci-cd/accessibility/-/merge_requests/9). -You can [view job artifacts in your browser](../pipelines/job_artifacts.md#download-job-artifacts). +You can [view job artifacts in your browser](../jobs/job_artifacts.md#download-job-artifacts). NOTE: For GitLab versions earlier than 12.9, use `include:remote` and @@ -74,3 +79,5 @@ The job definition provided by the template does not support Kubernetes. You cannot pass configurations into Pa11y via CI configuration. To change the configuration, edit a copy of the template in your CI file. + +<!--- end_remove -->
\ No newline at end of file diff --git a/doc/ci/testing/browser_performance_testing.md b/doc/ci/testing/browser_performance_testing.md index ff013f0037e..600b1a2cf4b 100644 --- a/doc/ci/testing/browser_performance_testing.md +++ b/doc/ci/testing/browser_performance_testing.md @@ -1,13 +1,18 @@ --- stage: Verify -group: Pipeline Insights +group: Pipeline Execution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments --- +<!--- start_remove The following content will be removed on remove_date: '2024-05-22' --> # Browser Performance Testing **(PREMIUM)** > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/3507) in GitLab 10.3. +WARNING: +This feature was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/388719) in GitLab 15.9 +and is planned for removal in 17.0. This change is a breaking change. + If your application offers a web interface and you're using [GitLab CI/CD](../index.md), you can quickly determine the rendering performance impact of pending code changes in the browser. diff --git a/doc/ci/testing/code_coverage.md b/doc/ci/testing/code_coverage.md new file mode 100644 index 00000000000..bd1246d2f78 --- /dev/null +++ b/doc/ci/testing/code_coverage.md @@ -0,0 +1,129 @@ +--- +stage: Verify +group: Pipeline Execution +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments +--- + +# Code coverage **(FREE)** + +Use code coverage to provide insights on what source code is being validated by a test suite. Code coverage is one of many test metrics that can determine software performance and quality. + +## View Code Coverage results + +Code Coverage results are shown in: + +- Merge request widget +- Project repository analytics +- Group repository analytics +- Repository badge + +For more information on test coverage visualization in the file diff of the MR, see [Test Coverage Visualization](test_coverage_visualization.md). + +### View code coverage results in the MR + +If you use test coverage in your code, you can use a regular expression to +find coverage results in the job log. You can then include these results +in the merge request in GitLab. + +If the pipeline succeeds, the coverage is shown in the merge request widget and +in the jobs table. If multiple jobs in the pipeline have coverage reports, they are +averaged. + + + + + +#### Add test coverage results using `coverage` keyword + +To add test coverage results to a merge request using the project's `.gitlab-ci.yml` file, provide a regular expression +using the [`coverage`](../yaml/index.md#coverage) keyword. + +#### Test coverage examples + +Use this regex for commonly used test tools. + +<!-- vale gitlab.Spelling = NO --> + +- Simplecov (Ruby). Example: `/\(\d+.\d+\%\) covered/`. +- pytest-cov (Python). Example: `/(?i)total.*? (100(?:\.0+)?\%|[1-9]?\d(?:\.\d+)?\%)$/`. +- Scoverage (Scala). Example: `/Statement coverage[A-Za-z\.*]\s*:\s*([^%]+)/`. +- `pest --coverage --colors=never` (PHP). Example: `/^\s*Cov:\s*\d+\.\d+?%$/`. +- `phpunit --coverage-text --colors=never` (PHP). Example: `/^\s*Lines:\s*\d+.\d+\%/`. +- gcovr (C/C++). Example: `/^TOTAL.*\s+(\d+\%)$/`. +- `tap --coverage-report=text-summary` (NodeJS). Example: `/^Statements\s*:\s*([^%]+)/`. +- `nyc npm test` (NodeJS). Example: `/All files[^|]*\|[^|]*\s+([\d\.]+)/`. +- `jest --ci --coverage` (NodeJS). Example: `/All files[^|]*\|[^|]*\s+([\d\.]+)/`. +- excoveralls (Elixir). Example: `/\[TOTAL\]\s+(\d+\.\d+)%/`. +- `mix test --cover` (Elixir). Example: `/\d+.\d+\%\s+\|\s+Total/`. +- JaCoCo (Java/Kotlin). Example: `/Total.*?([0-9]{1,3})%/`. +- `go test -cover` (Go). Example: `/coverage: \d+.\d+% of statements/`. +- .NET (OpenCover). Example: `/(Visited Points).*\((.*)\)/`. +- .NET (`dotnet test` line coverage). Example: `/Total\s*\|\s*(\d+(?:\.\d+)?)/`. +- tarpaulin (Rust). Example: `/^\d+.\d+% coverage/`. +- Pester (PowerShell). Example: `/Covered (\d+\.\d+%)/`. + +<!-- vale gitlab.Spelling = YES --> + +### View history of project code coverage + +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/209121) the ability to download a `.csv` in GitLab 12.10. +> - Graph [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/33743) in GitLab 13.1. + +To see the evolution of your project code coverage over time, +you can view a graph or download a CSV file with this data. + +1. On the top bar, select **Main menu > Projects** and find your project. +1. On the left sidebar, select **Analytics > Repository**. + +The historic data for each job is listed in the dropdown list above the graph. + +To view a CSV file of the data, select **Download raw data (`.csv`)**. + + + +### View history of group code coverage **(PREMIUM)** + +To see the all the project's code coverage under a group over time, you can find view [group repository analytics](../../user/group/repositories_analytics/index.md). + + + +### Pipeline badges + +You can use [pipeline badges](../../user/project/badges.md#test-coverage-report-badges) to indicate the pipeline status and +test coverage of your projects. These badges are determined by the latest successful pipeline. + +## Coverage check approval rule **(PREMIUM)** + +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/15765) in GitLab 14.0. +> - [Made configurable in Project Settings](https://gitlab.com/gitlab-org/gitlab/-/issues/331001) in GitLab 14.1. + +When merging a request that would cause the project's test coverage to decline, you can stipulate that such merge requests require approval by selected users or a group. + +Follow these steps to enable the `Coverage-Check` MR approval rule: + +1. Set up a [`coverage`](../yaml/index.md#coverage) regular expression for all jobs you want to include in the overall coverage value. +1. Go to your project and select **Settings > Merge requests**. +1. Under **Merge request approvals**, select **Enable** next to the `Coverage-Check` approval rule. +1. Select the **Target branch**. +1. Set the number of **Approvals required** to greater than zero. +1. Select the users or groups to provide approval. +1. Select **Add approval rule**. + + + +## Troubleshooting + +### Remove color codes from code coverage + +Some test coverage tools output with ANSI color codes that aren't +parsed correctly by the regular expression. This causes coverage +parsing to fail. + +Some coverage tools do not provide an option to disable color +codes in the output. If so, pipe the output of the coverage tool through a one-line script that strips the color codes. + +For example: + +```shell +lein cloverage | perl -pe 's/\e\[?.*?[\@-~]//g' +``` diff --git a/doc/ci/testing/code_quality.md b/doc/ci/testing/code_quality.md index 4b826991bb5..367777960b5 100644 --- a/doc/ci/testing/code_quality.md +++ b/doc/ci/testing/code_quality.md @@ -44,6 +44,7 @@ Code Quality results are shown in the: - Merge request widget - Merge request changes view - Pipeline details view +- Project quality view ### Merge request widget @@ -73,6 +74,12 @@ tab of the pipeline's details page.  +### Project quality view **(ULTIMATE)** + +The project quality view displays an overview of the code quality findings. The view can be found under **Analytics > CI/CD**, and requires [`project_quality_summary_page`](../../user/feature_flags.md) feature flag to be enabled for this particular project. + + + ## Enable Code Quality Prerequisites: @@ -119,7 +126,7 @@ Quality because: This alternative configuration uses socket binding to share the Runner's Docker daemon with the job environment. Before implementing this configuration, consider its -[limitations](../docker/using_docker_build.md#use-docker-socket-binding). +[limitations](../docker/using_docker_build.md#use-the-docker-executor-with-docker-socket-binding). To use private runners: @@ -253,7 +260,7 @@ code_quality: ``` The full JSON file is available as a -[downloadable artifact](../pipelines/job_artifacts.md#download-job-artifacts) of the `code_quality` +[downloadable artifact](../jobs/job_artifacts.md#download-job-artifacts) of the `code_quality` job. ### Download output in JSON and HTML format @@ -280,7 +287,7 @@ code_quality_html: ``` Both the JSON and HTML files are available as -[downloadable artifacts](../pipelines/job_artifacts.md#download-job-artifacts) of the `code_quality` +[downloadable artifacts](../jobs/job_artifacts.md#download-job-artifacts) of the `code_quality` job. ### Download output in only HTML format @@ -304,7 +311,7 @@ code_quality: ``` The HTML file is available as a -[downloadable artifact](../pipelines/job_artifacts.md#download-job-artifacts) of the `code_quality` +[downloadable artifact](../jobs/job_artifacts.md#download-job-artifacts) of the `code_quality` job. ## Use Code Quality with merge request pipelines @@ -448,6 +455,7 @@ properties: | Name | Description | | ---------------------- | ----------------------------------------------------------------------------------------- | | `description` | A description of the code quality violation. | +| `check_name` | A unique name representing the static analysis check that emitted this issue. | | `fingerprint` | A unique fingerprint to identify the code quality violation. For example, an MD5 hash. | | `severity` | A severity string (can be `info`, `minor`, `major`, `critical`, or `blocker`). | | `location.path` | The relative path to the file containing the code quality violation. | @@ -471,6 +479,7 @@ Example: [ { "description": "'unused' is assigned a value but never used.", + "check_name": "no-unused-vars", "fingerprint": "7815696ecbf1c96e6894b779456d330e", "severity": "minor", "location": { diff --git a/doc/ci/testing/fail_fast_testing.md b/doc/ci/testing/fail_fast_testing.md index 4ad1656c8d6..6b1ed4a594d 100644 --- a/doc/ci/testing/fail_fast_testing.md +++ b/doc/ci/testing/fail_fast_testing.md @@ -1,6 +1,6 @@ --- stage: Verify -group: Pipeline Insights +group: Pipeline Execution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments --- @@ -34,7 +34,7 @@ Fail fast testing gives you a faster feedback loop from the pipeline. It lets yo know quickly that the new tests are passing and the new functionality did not break other tests. -## Requirements +## Prerequisites This template requires: diff --git a/doc/ci/testing/img/code_coverage_graph_v13_1.png b/doc/ci/testing/img/code_coverage_graph_v13_1.png Binary files differnew file mode 100644 index 00000000000..da92a1b4a86 --- /dev/null +++ b/doc/ci/testing/img/code_coverage_graph_v13_1.png diff --git a/doc/ci/testing/img/code_coverage_group_report.png b/doc/ci/testing/img/code_coverage_group_report.png Binary files differnew file mode 100644 index 00000000000..3e28a9b4cdd --- /dev/null +++ b/doc/ci/testing/img/code_coverage_group_report.png diff --git a/doc/ci/testing/img/code_quality_summary_15_9.png b/doc/ci/testing/img/code_quality_summary_15_9.png Binary files differnew file mode 100644 index 00000000000..60077123488 --- /dev/null +++ b/doc/ci/testing/img/code_quality_summary_15_9.png diff --git a/doc/ci/testing/img/coverage_check_approval_rule_14_1.png b/doc/ci/testing/img/coverage_check_approval_rule_14_1.png Binary files differnew file mode 100644 index 00000000000..8c1d005e074 --- /dev/null +++ b/doc/ci/testing/img/coverage_check_approval_rule_14_1.png diff --git a/doc/ci/testing/img/pipelines_test_coverage_build.png b/doc/ci/testing/img/pipelines_test_coverage_build.png Binary files differnew file mode 100644 index 00000000000..7eaba1a256f --- /dev/null +++ b/doc/ci/testing/img/pipelines_test_coverage_build.png diff --git a/doc/ci/testing/img/pipelines_test_coverage_mr_widget.png b/doc/ci/testing/img/pipelines_test_coverage_mr_widget.png Binary files differnew file mode 100644 index 00000000000..fbcd612f3f2 --- /dev/null +++ b/doc/ci/testing/img/pipelines_test_coverage_mr_widget.png diff --git a/doc/ci/testing/index.md b/doc/ci/testing/index.md index 41d474f0e60..a8fb6d688d7 100644 --- a/doc/ci/testing/index.md +++ b/doc/ci/testing/index.md @@ -1,6 +1,6 @@ --- stage: Verify -group: Pipeline Insights +group: Pipeline Execution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments --- @@ -14,8 +14,9 @@ display reports or link to important information directly from [merge requests]( | [Accessibility Testing](accessibility_testing.md) | Automatically report A11y violations for changed pages in merge requests. | | [Browser Performance Testing](browser_performance_testing.md) | Quickly determine the browser performance impact of pending code changes. | | [Load Performance Testing](load_performance_testing.md) | Quickly determine the server performance impact of pending code changes. | +| [Code Coverage](code_coverage.md) | See code coverage results in the MR, project or group. | | [Code Quality](code_quality.md) | Analyze your source code quality using the [Code Climate](https://codeclimate.com/) analyzer and show the Code Climate report right in the merge request widget area. | -| [Display arbitrary job artifacts](../yaml/index.md#artifactsexpose_as) | Configure CI pipelines with the `artifacts:expose_as` parameter to directly link to selected [artifacts](../pipelines/job_artifacts.md) in merge requests. | +| [Display arbitrary job artifacts](../yaml/index.md#artifactsexpose_as) | Configure CI pipelines with the `artifacts:expose_as` parameter to directly link to selected [artifacts](../jobs/job_artifacts.md) in merge requests. | | [Unit test reports](unit_test_reports.md) | Configure your CI jobs to use Unit test reports, and let GitLab display a report on the merge request so that it's easier and faster to identify the failure without having to check the entire job log. | | [License Compliance](../../user/compliance/license_compliance/index.md) | Manage the licenses of your dependencies. | | [Metrics Reports](metrics_reports.md) | Display the Metrics Report on the merge request so that it's fast and easier to identify changes to important metrics. | diff --git a/doc/ci/testing/load_performance_testing.md b/doc/ci/testing/load_performance_testing.md index 7e527fae562..2897d7fe0ab 100644 --- a/doc/ci/testing/load_performance_testing.md +++ b/doc/ci/testing/load_performance_testing.md @@ -1,13 +1,18 @@ --- stage: Verify -group: Pipeline Insights +group: Pipeline Execution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments --- -# Load Performance Testing **(PREMIUM)** +<!--- start_remove The following content will be removed on remove_date: '2024-05-22' --> +# Load Performance Testing (deprecated) **(PREMIUM)** > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/10683) in GitLab 13.2. +WARNING: +This feature was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/388723) in GitLab 15.9 +and is planned for removal in 17.0. This change is a breaking change. + With Load Performance Testing, you can test the impact of any pending code changes to your application's backend in [GitLab CI/CD](../index.md). @@ -161,7 +166,7 @@ For example: 1. In the `review` job: 1. Capture the dynamic URL and save it into a `.env` file, for example, `echo "ENVIRONMENT_URL=$CI_ENVIRONMENT_URL" >> review.env`. - 1. Set the `.env` file to be a [job artifact](../pipelines/job_artifacts.md). + 1. Set the `.env` file to be a [job artifact](../jobs/job_artifacts.md). 1. In the `load_performance` job: 1. Set it to depend on the review job, so it inherits the environment file. 1. Set the `K6_DOCKER_OPTIONS` variable with the [Docker CLI option for environment files](https://docs.docker.com/engine/reference/commandline/run/#set-environment-variables--e---env---env-file), for example `--env-file review.env`. @@ -199,3 +204,5 @@ load_performance: rules: - if: $CI_COMMIT_BRANCH # Modify to match your pipeline rules, or use `only/except` if needed. ``` + +<!--- end_remove --> diff --git a/doc/ci/testing/metrics_reports.md b/doc/ci/testing/metrics_reports.md index e084e4d3bc7..9257ba8990e 100644 --- a/doc/ci/testing/metrics_reports.md +++ b/doc/ci/testing/metrics_reports.md @@ -1,6 +1,6 @@ --- stage: Verify -group: Pipeline Insights +group: Pipeline Execution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments --- diff --git a/doc/ci/testing/test_coverage_visualization.md b/doc/ci/testing/test_coverage_visualization.md index e2a1a4a2c5e..31d1b7f3337 100644 --- a/doc/ci/testing/test_coverage_visualization.md +++ b/doc/ci/testing/test_coverage_visualization.md @@ -1,6 +1,6 @@ --- stage: Verify -group: Pipeline Insights +group: Pipeline Execution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments --- @@ -33,7 +33,7 @@ This format was originally developed for Java, but most coverage analysis framew for other languages have plugins to add support for it, like: - [simplecov-cobertura](https://rubygems.org/gems/simplecov-cobertura) (Ruby) -- [gocover-cobertura](https://github.com/boumenot/gocover-cobertura) (Golang) +- [gocover-cobertura](https://github.com/boumenot/gocover-cobertura) (Go) Other coverage analysis frameworks support the format out of the box, for example: @@ -54,8 +54,8 @@ of times the line was checked by tests. Uploading a test coverage report does not enable: -- [Test coverage results in merge requests](../pipelines/settings.md#merge-request-test-coverage-results). -- [Code coverage history](../pipelines/settings.md#view-code-coverage-history). +- [Test coverage results in merge requests](code_coverage.md#view-code-coverage-results-in-the-mr). +- [Code coverage history](code_coverage.md#view-history-of-project-code-coverage). You must configure these separately. @@ -112,24 +112,14 @@ attempts to build the full path by: #### Path correction example -As an example, a project with: +As an example, a C# project with: -- A full path of `test-org/test-project`. +- A full path of `test-org/test-cs-project`. - The following files relative to the project root: ```shell Auth/User.cs Lib/Utils/User.cs - src/main/java - ``` - -In the: - -- Cobertura XML, the `filename` attribute in the `class` element assumes the value is a relative - path to the project's root: - - ```xml - <class name="packet.name" filename="src/main/java" line-rate="0.0" branch-rate="0.0" complexity="5"> ``` - `sources` from Cobertura XML, the following paths in the format @@ -137,8 +127,8 @@ In the: ```xml <sources> - <source>/builds/test-org/test-project/Auth</source> - <source>/builds/test-org/test-project/Lib/Utils</source> + <source>/builds/test-org/test-cs-project/Auth</source> + <source>/builds/test-org/test-cs-project/Lib/Utils</source> </sources> ``` @@ -153,6 +143,29 @@ The parser: 100 iterations. If it reaches this limit without finding a matching path in the file tree, the class is not included in the final coverage report. +Automatic class path correction also works for a Java project with: + +- A full path of `test-org/test-java-project`. +- The following files relative to the project root: + + ```shell + src/main/java/com/gitlab/security_products/tests/App.java + ``` + +- `sources` from Cobertura XML: + + ```xml + <sources> + <source>/builds/test-org/test-java-project/src/main/java/</source> + </sources> + ``` + +- `class` element with the `filename` value of `com/gitlab/security_products/tests/App.java`: + + ```xml + <class name="com.gitlab.security_products.tests.App" filename="com/gitlab/security_products/tests/App.java" line-rate="0.0" branch-rate="0.0" complexity="6.0"> + ``` + NOTE: Automatic class path correction only works on `source` paths in the format `<CI_BUILDS_DIR>/<PROJECT_FULL_PATH>/...`. The `source` is ignored if the path does not follow this pattern. The parser assumes that the @@ -261,10 +274,7 @@ coverage-jdk11: ### Python example -The following [`.gitlab-ci.yml`](../yaml/index.md) example for Python uses [pytest-cov](https://pytest-cov.readthedocs.io/) to collect test coverage data and [coverage.py](https://coverage.readthedocs.io/) to convert the report to use full relative paths. -The information isn't displayed without the conversion. - -This example assumes that the code for your package is in `src/` and your tests are in `tests.py`: +The following [`.gitlab-ci.yml`](../yaml/index.md) example uses [pytest-cov](https://pytest-cov.readthedocs.io/) to collect test coverage data: ```yaml run tests: @@ -272,9 +282,7 @@ run tests: image: python:3 script: - pip install pytest pytest-cov - - coverage run -m pytest - - coverage report - - coverage xml + - pytest --cov --cov-report term --cov-report xml:coverage.xml coverage: '/(?i)total.*? (100(?:\.0+)?\%|[1-9]?\d(?:\.\d+)?\%)$/' artifacts: reports: diff --git a/doc/ci/testing/unit_test_report_examples.md b/doc/ci/testing/unit_test_report_examples.md index 87426fc8496..c63e225a2a7 100644 --- a/doc/ci/testing/unit_test_report_examples.md +++ b/doc/ci/testing/unit_test_report_examples.md @@ -1,6 +1,6 @@ --- stage: Verify -group: Pipeline Insights +group: Pipeline Execution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments --- @@ -274,3 +274,24 @@ phpunit: reports: junit: report.xml ``` + +## Rust + +This example uses [cargo2junit](https://crates.io/crates/cargo2junit), +which is installed in the current directory. +To retrieve JSON output from `cargo test`, you must enable the nightly compiler. + +```yaml +run unittests: + image: rust:latest + stage: test + before_script: + - cargo install --root . cargo2junit + script: + - cargo test -- -Z unstable-options --format json --report-time | bin/cargo2junit > report.xml + artifacts: + when: always + reports: + junit: + - report.xml +``` diff --git a/doc/ci/testing/unit_test_reports.md b/doc/ci/testing/unit_test_reports.md index 0fe9b2b6d64..88a5d90d30e 100644 --- a/doc/ci/testing/unit_test_reports.md +++ b/doc/ci/testing/unit_test_reports.md @@ -1,6 +1,6 @@ --- stage: Verify -group: Pipeline Insights +group: Pipeline Execution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments --- |
