We intend to use the edited event to react to base branch changes - but
before this change, we also ran those jobs on simple edits like title or
description.
While this works for some of the quicker jobs, it will not be
sustainable for all evaluation-related jobs. But evaluation needs to be
re-triggered on a base branch change as well, thus this change.
(cherry picked from commit 9b01e09a35)
All workflows where it's remotely useful now trigger on a pull_request
event when the workflow file itself is changed. This gives us basic
sanity testing of changes to workflow files itself and reduces the need
for manual tests in forks.
ARM runners are supposed to be more energy efficient than x86. Also,
from limited testing, they appear to be faster for the eval jobs as
well. Average run time for the "Outpaths (x86_64-linux)" job was 4m 27s,
so far. In the first run, this job came in at 3m 9s. This effect did not
show for other jobs, yet.
The following two exceptions are made right now:
- nixpkgs-lib-tests currently fails on the ARM runner building Nix 2.3
- nixpkgs-vet is currently pinned to a x86_64-linux only binary release
Because of the branches filter, the job would **not** re-run when only
the base-branch was changed, thus leaving the contributor with a failed
check.
With this change, the job should be triggered and then skipped in this
case, so the check in the list should be replaced with a skip.
Note, this also means that this step will show up in every PR as
skipped, even when it was never failed before.
Same top-level ordering of keys / empty lines and same indentation for
yaml lists. One blank line between each step.
Makes it easier to read and compare the workflows.
