Skip to content

ci: stop duplicate and outdated check runs - #4

Open
npmccallum wants to merge 1 commit into
mainfrom
bot/devtree/ci-run-groups
Open

npmccallum wants to merge 1 commit into
mainfrom
bot/devtree/ci-run-groups

Conversation

@npmccallum

Copy link
Copy Markdown
Contributor

Summary

A workflow is a file that tells GitHub which automatic checks to run
and when. This change makes the checks workflow (the ci.yml file that
runs the tests and other checks) run once for each update to a pull
request, and stop an older run when a newer one starts.

Fixes #3

Approach

A branch is a named line of work in the repository, and the main
branch is the shared branch that changes are merged into. A push means
sending new commits up to GitHub.

The checks workflow runs for pull requests, for pushes to the main
branch, and when someone starts it by hand. A push to any other branch
does not start it, because the pull request for that branch already
runs the same checks.

GitHub lets a workflow give each run a group label, and only one run
with the same label goes at a time. On the main branch, every run gets
its own label, so no run there is ever stopped. Anywhere else, a newer
run for the same pull request, or a newer run started by hand on the
same branch, stops the older one.

The group label settings are the same as in the open change
pichi-vm/burrow#5, which has not been merged
yet. Only ci.yml changed. The docs workflow (the docs.yml file that
builds the code documentation) and the list of checks and their names
were not touched.

Verification

  • All local tests were run and passed for every commit in this series independently
  • This series has one commit. Every check below ran on it in a clean copy of the repository, on Linux on an x86_64 machine (a common PC processor type), and each one finished with exit code 0.
  • actionlint 1.7.12 (checks workflow files for mistakes) found no problems in ci.yml or docs.yml.
  • hawkeye 6.5.0 (checks every source file has its license header) found no file missing one.
  • git diff --check (looks for stray spaces at line ends) found nothing.
  • cargo fmt (checks code formatting) found nothing to change.
  • cargo clippy (Rust's code-quality checker), with warnings treated as errors, gave no warnings.
  • Clippy and the tests used --all-targets --all-features, which builds and checks every part of the code and every optional feature.
  • cargo test: 105 passed, 0 failed, 0 ignored. Running it with --ignored found no ignored tests to run.
  • Doc tests (the code examples in the documentation, run as tests): 1 passed and 1 ignored. The ignored one also passed when run with --ignored.
  • cargo deny (checks the dependencies, meaning the outside Rust libraries, called crates, that this code uses) passed all four parts: known security advisories (advisories), banned or duplicate crates (bans), licenses, and allowed download sources (sources).
  • gitlint (checks the commit message format) passed.
  • The docs built with --cfg docsrs (builds the docs the way docs.rs, the public Rust documentation site, does) with no errors.
  • Rebuilding the test data files with tests/data/regenerate.sh gave no changes.
  • The fuzz targets (programs that feed lots of random input to the code to look for crashes) built. Each one then ran for 60 seconds with no crash: fuzz_parse 5,594,538 inputs, fuzz_overlay 2,357,473, and fuzz_owned 2,438,838.
  • Skipped: none. The checks workflow has no matrix (a list of different systems the automatic checks run each job on). Every job runs only on Ubuntu 24.04 (the Linux system GitHub's automatic check machines use), so no other system was left out.
  • The two behavior changes (no extra run for a branch push, and an older run being stopped) can only be seen on GitHub.

A workflow is a file that tells GitHub which automatic checks to run
and when. A branch is a named line of work in the repository, and the
main branch is the shared branch that changes are merged into. A push
means sending new commits up to GitHub.

This workflow runs the checks for pull requests, for pushes to the
main branch, and when someone starts it by hand. A push to any other
branch does not start it, because the pull request for that branch
already runs the same checks.

GitHub lets a workflow give each run a group label, and only one run
with the same label goes at a time. On the main branch, every run gets
its own label, so no run there is ever stopped. Anywhere else, a newer
run for the same pull request, or a newer run started by hand on the
same branch, stops the older one.

Fixes #3

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

ci: avoid duplicate push/PR runs and cancel superseded PR revisions

1 participant