| Message ID | 20230601181040.GC4167886@coredump.intra.peff.net (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | d88d727143c3444897a9fdfe2d443c72808bcc97 |
| Headers | show |
| Series | ci sanitizer cleanups and performance improvements | expand |
diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml index 2114303b7d..079645b776 100644 --- a/.github/workflows/main.yml +++ b/.github/workflows/main.yml @@ -246,9 +246,6 @@ jobs: fail-fast: false matrix: vector: - - jobname: linux-clang - cc: clang - pool: ubuntu-latest - jobname: linux-sha256 cc: clang pool: ubuntu-latest
Since the linux-asan-ubsan job runs using clang under Linux, there is not much point in running a separate clang job. Any errors that a normal clang compile-and-test cycle would find are likely to be a subset of what the sanitizer job will find. Since this job takes ~14 minutes to run in CI, this shaves off some of our CPU load (though it does not affect end-to-end runtime, since it's typically run in parallel and is not the longest job). Technically this provides us with slightly less signal for a given run, since you won't immediately know if a failure in the sanitizer job is from using clang or from the sanitizers themselves. But it's generally obvious from the logs, and anyway your next step would be to fix the probvlem and re-run CI, since we expect all of these jobs to pass normally. Signed-off-by: Jeff King <peff@peff.net> --- Obviously not necessary, but just seemed like another easy way to trim our resource usage. Really, the same logic could apply before my series to the linux-gcc job, which is similarly redundant. .github/workflows/main.yml | 3 --- 1 file changed, 3 deletions(-)