This broke when we moved the check-cherry-picks workflow into the bigger
PR workflow. At this time, the "workflow run" became the whole PR
workflow, which includes many more than just 1 job, thus the assumption
in `jobs[0]` doesn't hold anymore.
Most of the checks we do for cherry-picks are dismissable warnings, with
one exception: When a commit hash has been found, but this hash is not
available in any of the pickable branches, we raise this with
severity=error. This should also *block* the merge and not be
dismissable. That's because this is a fixable issue in every case.
Previously, when the diff contained a context line with ```, this would
end the code block and entirely break the markdown rendering.
Now we use the html code blocks provided by `core.summary` and properly
escape the content, so that it never escapes via html tags.
This reduces noise that the cherry-pick reviews produce when formatting
related conflicts had to be resolved. We only do this in the
length-limited review comment, though. All changes, including
whitespace, can still be double-checked in the job log if needed.
This turns the check-cherry-pick script into a github-script based
JavaScript program. This makes it much easier to extend to check reverts
or merge commits later on.
Except:
- Instances in documentation, because people in older versions
can't switch to nixfmt yet due to it having pointed to nixfmt-classic
before
- In code that runs based on a CI Nixpkgs version, which is also a bit
older still
- In update script shebangs, because many of them don't pin Nixpkgs, and run
with whatever is in NIX_PATH (and it's not easy to fix this, see
https://github.com/NixOS/nixpkgs/issues/425551)
Since all github-scripts need to be written in commonjs, we now default
to it by not setting package.json. Support from editors for .js files is
slightly better than .cjs. To still allow using module imports in the
test runner script, we trick node into loading the script itself as a
module again via `--import ./run`.
This just moves things around to use less specific naming - `labels` is
only *one* script that can potentially be run locally while still being
written in github-script. Later, we can add more.
This fixes labeling in the context of the `pull_request` trigger. Of
course, this was supposed to immediately label rebuilds after eval
finishes, but we somehow lost this along the way. Rebuilds are still
labeled fairly soon, because the scheduled trigger will pick up the same
PR within 10 minutes again and then apply the rebuild labels. But of
course, immediate is better.
The reason this happened is, that we're looking at `item.pull_request`
only. This is the correct distinction between "issue items" and "pull
request items", which we both get back from the /issues endpoint. But
the payload for the `pull_request*` event doesn't contain this, so
labeling in this case was treated like an issue and skipped the whole
pull request part.
When backporting a PR from master -> 25.05 -> 24.11 in a chain, the last
cherry-pick will have two references to different commits in it. If
there was conflict resolution in the first step, the diff will show up
again in the last step. This can be fixed by comparing against the right
hash - always the last one.
Some jobs purposefully only run on certain base or head branches. By
centralizing the logic, parts of it can easily be re-used later. Also,
this gives them an explicit name and thus makes them easier to
understand.
Instead of deleting each label separately and then making another call
to add new labels, this replaces all labels at once, thus saving API
calls in some cases. Also, the labels are now managed in object-style
compared to the array-style before. This allows putting all the
knowledge about each label into a single place instead of in multiple
places. For example, the rebuild labels had to be special cased in the
workflow before - and the nix code to compare had to match that. Also,
the approval labels had to be considered in the `before` and `after`
phases.
The next commit shows how easy it is to add a new label now.
Those have not been working since before the migration from OfBorg.
Those `rebuildsByKernel` are an attrset of lists coming from
`groupByKernel` (also see lengthy comment at the top of the file) - thus
we need `lib.elem` instead.
It currently fails with this:
```
error: lib.fileset.toSource: `root`
(/tmp/nix-shell-19054-0/tmp.MB62qzBqsj/base) is a string-like value, but
it should be a path instead.
Paths in strings are not supported by `lib.fileset`, use
`lib.sources` or derivations instead.
```
Resolves#416175
Most workflow files are already well formatted, but to make it easier to
keep it that way, we can add yamlfmt.
I personally have a preference for non-indented arrays for YAML, but
wanted to avoid bigger diffs here - the status-quo clearly are indented
arrays.
Some changes are made manually to the get-merge-commit action and the
issue templates. Those would otherwise make yamlfmt misbehave on those.
