Without a target run, we won't get any rebuild labels, rebuild counts or
maintainer pings. This might have been correct before #373935, but by
now we run eval on all commits on the target branch, so we should treat
it as a failure if we can't find the run.
(cherry picked from commit 86a38d48fb)
Apparently the skipping needs to happen on the calling workflow,
otherwise those workflows show up as "failed" in forks instead of
skipped.
(cherry picked from commit d725592cd1)
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.
(cherry picked from commit 88afad8833)
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.
(cherry picked from commit f9f5325ad9)
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.
(cherry picked from commit 9ea74225cc)
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".
(cherry picked from commit 3e9f5c05ea)
It seems odd to exclude PRs against release branches for those checks -
especially when not excluding PRs against staging-** variants at the
same time.
(cherry picked from commit 58f8c536c6)
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.
(cherry picked from commit b64d5e1c0c)
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.
(cherry picked from commit 88afad8833)
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.
(cherry picked from commit 72fd375d1c)
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?
(cherry picked from commit aa7335ca5f)
Additionally, no permissions are needed so set it to an empty set
Signed-off-by: John Titor <50095635+JohnRTitor@users.noreply.github.com>
(cherry picked from commit 3ff50a219b)
This is to ensure that the eval summary is still set as commit status,
even when the review requests fail due to too many reviewers.
(cherry picked from commit 3c9794d06e)
The ${{ }} syntax is best avoided in scripts. While it wouldn't be a
problem here, let's do this for consistency
(cherry picked from commit ab248be504)
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
(cherry picked from commit 0ebab0bcca)
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.
(cherry picked from commit b844cba4e6)
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.
(cherry picked from commit b9d800d468)
