From 5ce83552e545ee3e99b4480abbbfb9929bd8e0dd Mon Sep 17 00:00:00 2001 From: Onsi Fakhouri Date: Tue, 21 May 2024 09:26:03 -0600 Subject: [PATCH] add --fail-on-empty to recommended CI flags in docs --- docs/index.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/index.md b/docs/index.md index 21865f61a..a7fce4a87 100644 --- a/docs/index.md +++ b/docs/index.md @@ -3696,7 +3696,7 @@ When running in CI you must make sure that the version of the `ginkgo` CLI you a Once you have `ginkgo` running on CI, you'll want to pick and choose the optimal set of flags for your test runs. We recommend the following set of flags when running in a continuous integration environment: ```bash -go run github.com/onsi/ginkgo/v2/ginkgo -r --procs=N --compilers=N --randomize-all --randomize-suites --fail-on-pending --keep-going --cover --coverprofile=cover.profile --race --trace --json-report=report.json --timeout=TIMEOUT --poll-progress-after=Xs --poll-progress-interval=Ys +go run github.com/onsi/ginkgo/v2/ginkgo -r --procs=N --compilers=N --randomize-all --randomize-suites --fail-on-pending --fail-on-empty --keep-going --cover --coverprofile=cover.profile --race --trace --json-report=report.json --timeout=TIMEOUT --poll-progress-after=Xs --poll-progress-interval=Ys ``` Here's why: @@ -3705,6 +3705,8 @@ Here's why: - `-procs=N` will run each suite in parallel. This can substantially speed up suites and you should experiment with different values of `N`. Note that it is not recommended that you run specs in parallel with `-p` on CI. Some CI services run on shared machines that will report (e.g.) `32` cores but will not actually give an individual account access to all those compute resources! - `--compilers=N` will control how many cores to use to compile suites in parallel. You may need to set this explicitly to avoid accidentally trying to use all `32` cores on that CI machine! - `--randomize-all` and `--randomize-suites` will randomize all specs and randomize the order in which suites run. This will help you suss out spec pollution early! +- `--fail-on-pending` will fail the suite if it contains any pending specs. These are generally only used while developing the suite and should not be committed. +- `--fail-on-empty` will fail the suite if it contains no specs or if all specs have been filtered out. This can help you ensure that the CLI filters have not filtered out all specs (which typically means the filters are malformed). - `--keep-going` will instruct Ginkgo to keep running suites, even after a suite fails. This can help you get a set of all failures instead of stopping after the first failed suite. - `--cover` and `--coverprofile=cover.profile` will compute coverage scores and generate a single coverage file for all your specs. - `--race` will run the race detector.