|
| 1 | +Test Summary |
| 2 | +============ |
| 3 | + |
| 4 | + |
| 5 | + |
| 6 | + |
| 7 | +Produce an easy-to-read summary of your project's test data as part of your GitHub Actions CI/CD workflow. This helps you understand at-a-glance the impact to the changes in your pull requests, and see which changes are introducing new problems. |
| 8 | + |
| 9 | +* Integrates easily with your existing GitHub Actions workflow |
| 10 | +* Produces summaries from JUnit XML and TAP test output |
| 11 | +* Compatible with most testing tools for most development platforms |
| 12 | +* Customizable to show just a summary, just failed tests, or all test results. |
| 13 | + |
| 14 | +Getting Started |
| 15 | +--------------- |
| 16 | +To set up the test summary action, just add a few lines of YAML to your GitHub Actions workflow. For example, if your test harness produces JUnit XML outputs in the `test/results/` directory, and you want to produce a test summary in a file named `test-summary.md`, add a new step to your workflow YAML after your build and test step: |
| 17 | + |
| 18 | +```yaml |
| 19 | +- name: Test Summary |
| 20 | + uses: test-summary/action@v1 |
| 21 | + with: |
| 22 | + paths: "test/results/**/TEST-*.xml" |
| 23 | + output: test-summary.md |
| 24 | + if: always() |
| 25 | +``` |
| 26 | +
|
| 27 | +Update `paths` to match the test output file(s) that your test harness produces. You can specify glob patterns, including `**` to match the pattern recursively. In addition, you can specify multiple test paths on multiple lines. For example: |
| 28 | + |
| 29 | +```yaml |
| 30 | +- name: Test Summary |
| 31 | + uses: test-summary/action@v1 |
| 32 | + with: |
| 33 | + paths: | |
| 34 | + test-one/**/TEST-*.xml |
| 35 | + test-two/results/results.tap |
| 36 | + output: test-summary.md |
| 37 | + if: always() |
| 38 | +``` |
| 39 | + |
| 40 | +> Note the `if: always()` conditional in this workflow step: you should always use this so that the test summary creation step runs _even if_ the previous steps have failed. This allows your test step to fail -- due to failing tests -- but still produce a test summary. |
| 41 | + |
| 42 | +Upload the markdown |
| 43 | +------------------- |
| 44 | +The prior "getting started" step generates a summary in GitHub-flavored Markdown (GFM). Once the markdown is generated, you can upload it as a build artifact, add it to a pull request comment, or add it to an issue. For example, to upload the markdown generated in the prior example as a build artifact: |
| 45 | + |
| 46 | +```yaml |
| 47 | +- name: Upload test summary |
| 48 | + uses: actions/upload-artifact@v3 |
| 49 | + with: |
| 50 | + name: test-summary |
| 51 | + path: test-summary.md |
| 52 | + if: always() |
| 53 | +``` |
| 54 | + |
| 55 | +Examples |
| 56 | +-------- |
| 57 | +There are examples for setting up a GitHub Actions step with many different platforms [in the examples repository](https://github.com/test-summary/examples). |
| 58 | + |
| 59 | +Options |
| 60 | +------- |
| 61 | +Options are specified on the [`with` map](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepswith) of the action. |
| 62 | + |
| 63 | +* **`paths`: the paths for input files** (required) |
| 64 | + One or more file [glob patterns](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet) that specify the test results files in JUnit XML or TAP format. |
| 65 | + |
| 66 | + * To specify a single file, provide it directly as a string value to the `paths` key. For example: |
| 67 | + |
| 68 | + ```yaml |
| 69 | + - uses: test-summary/action@v1 |
| 70 | + with: |
| 71 | + paths: "tests/results.xml" |
| 72 | + ``` |
| 73 | + |
| 74 | + * To specify multiple files, provide them as a multi-line string value to the `paths` key. For example: |
| 75 | + |
| 76 | + ```yaml |
| 77 | + - uses: test-summary/action@v1 |
| 78 | + with: |
| 79 | + paths: | |
| 80 | + tests-one/results.xml |
| 81 | + tests-two/results.xml |
| 82 | + tests-three/results.xml |
| 83 | + ``` |
| 84 | + |
| 85 | + * You can specify files as a [glob patterns](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet), allowing you to use wildcards to match multiple files. For example, to match all files named `TEST-*.xml` beneath the `tests` folder, recursively: |
| 86 | + |
| 87 | + ```yaml |
| 88 | + - uses: test-summary/action@v1 |
| 89 | + with: |
| 90 | + paths: "test/results/**/TEST-*.xml" |
| 91 | + ``` |
| 92 | + |
| 93 | +* **`output`: the output file to create** (required) |
| 94 | + This is the path to the output file to populate with the test summary markdown data. For example: |
| 95 | + |
| 96 | + ```yaml |
| 97 | + - uses: test-summary/action@v1 |
| 98 | + with: |
| 99 | + output: "test/results/summary.md" |
| 100 | + ``` |
| 101 | + |
| 102 | + This file is [GitHub Flavored Markdown (GFM)](https://github.github.com/gfm/) and may include permitted HTML. |
| 103 | + |
| 104 | +FAQ |
| 105 | +--- |
| 106 | +* How is the summary graphic generated? Does any of my data ever leave GitHub? |
| 107 | + None of your data ever leaves GitHub. Test results are read within GitHub Actions by the test-summary action, and a link to an SVG with the test results numbers is created. This the graphic is both fetched and subsequently cached by GitHub's image service. This service provides no referral information to remote hosts. This means that no information at all about your workflow - the repository name, test results, or other information - is available to the image generator service. |
| 108 | + |
| 109 | +Questions / Help / Contact |
| 110 | +-------------------------- |
| 111 | +Have questions? Need help? Visit [the discussion forum](https://github.com/test-summary/action/discussions). |
| 112 | + |
| 113 | +Copyright (c) 2022 Edward Thomson. Available under the MIT license. |
0 commit comments