This introduces some basic concepts used in these workflows and a common
terminology.
At the same time we remove some of the comments from various workflow
files, because they are assumed to be "general knowledge" through the
README.
We currently use two different "base" commits, but the same name. One of
them is the commit in which context the pull_request_target runs. The
other is the parent of the merge commit. Those are **not** necessarily
the same - see README introduced in the next commit for details.
Renaming one of them for clarity. Since the pull_request_target related
base commit is also called like that in GitHub Actions terminology, we
rename the other. The best I could come up with is "target".
It seems odd to exclude PRs against release branches for those checks -
especially when not excluding PRs against staging-** variants at the
same time.
No need for that limitation, which only artifically limits test-ability
of CI in forks.
Some other workflows like backports, cherry-pick checks and periodic
merges are very specific to the release branches and don't need to be
run in forks.
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.
mergedSha is available from needs.get-merge-commit, not needs.attrs.
Actionlint rightfully complains about that.
The code still works as expected because nixpkgs/ is checked out at
mergedSha, so the diff will be between mergedSha and baseSha.
This seems to be unused. It can be triggered manually, but is this
really done?
Is this superseded by the new eval checks or should we instead run this
regularly?
Since haskell-updates is based on master, but merges into staging, we
need to base it on a merge-base of staging and master. See #361143.
I'm a bit worried that the information GitHub uses for displaying
Pull-Requests becomes stale and this will “add” commits to the PR
compared to the base anyways. We'll find out, I suppose.
Filters out the PR author and avoids rerequesting reviews from people
that already left a review. In a future commit, this can be expanded to
also avoid requesting reviews from people not in the org
The handles can change over time and there's nothing guaranteeing the
ones in the maintainer list are up-to-date. In comparison GitHub IDs
never change.
Currently we need to rely on ofborg requesting reviews from package
maintainers, which takes a while with ofborg's eval queue. Since
recently we're doing faster evaluations with GitHub Actions, which contain all
necessary information to determine reviewers of changed packages the
same way ofborg does. This PR takes advantage of that.
Before the get-merge-commit was put into a separate workflow job, it ran
as a step, which then required skipping all subsequent steps
individually. This is not necessary anymore, because entire workflow
jobs can be skipped.
This commit consistently applies that change throughout all workflows.
After the introduction of the reusable get-merge-commit.yml workflow,
this now applies it on all remaining workflows that depend on a merge
commit. This ensures that CI doesn't fail for those PRs, which would
cause notifications to be sent, and the CI run to be marked as failed in
the list of runs.
Sometimes successful workflows trigger that condition,
see 3426066022:
Comparing against "1227849589"
Workflow not done, waiting 10 seconds before checking again
Workflow was not successful, cannot make comparison
Even though
$ gh api /repos/NixOS/nixpkgs/actions/runs/12278495895 --jq .conclusion
success
Let's print the conclusion when it's not "success" to debug this.
