Tatsh / deltona / 32103099753

100%

push

github

git: add retry-gh-jobs

Run failed GitHub Actions jobs again where the failure was not the
code's fault. Only the jobs that failed are restarted, so anything that
already passed is left alone.

A failure qualifies only when the name of the step that failed and the
text of the job's log both match one rule. The log decides. A step name
on its own proved too coarse against real data: Install dependencies
covered a rate limit, a stale yarn lockfile, and an OpenSSL build
failure, and only the first is worth running again.

The rules were derived from 7,882 runs across 108 repositories, of which
313 failed:

- Coveralls, on a server error. Suppressing it with fail-on-error was
  the alternative, and it is worse: a Coveralls outage would then pass
  silently and the missing coverage would surface much later.
- Install dependencies, on a rate or request limit only.
- python-appimage, on an anonymous API rate limit. Fixed at source in
  the workflow template, kept here as a backstop.

Dependabot update runs are never restarted. They arrive under the
dynamic event and are 188 of the 313 observed failures, they install
dependencies like any other run, and so without an explicit guard a rate
limited one would match the install rule. They are recreated with
@dependabot recreate rather than re-run.

Runs already attempted --max-attempts times are skipped, so a failure
that recurs on every attempt does not loop.

Nothing else is touched. A test failure, a type error, or any signature
not in the table is left alone, which is the safe direction for a
decision about whether to spend CI on a job again.

The rules live in code rather than in configuration. Deciding that a
failure was not the code's fault deserves review.

Signed-off-by: Andrew Udvare <audvare@gmail.com>

478 of 478 branches covered (100.0%)

Branch coverage included in aggregate %.

145 of 145 new or added lines in 2 files covered. (100.0%)

3941 of 3941 relevant lines covered (100.0%)

3.0 hits per line