The python-updates branch is not a "development" branch in the sense of
ci/README.md's classification. That's because it allows force pushes.
When rewrites are possible, cherry-picking from this branch should not
be allowed, because the commit references will potentially end up out of
sync.
These kind of branches are now termed "Work-in-Progress" branches. Up
until recently these branches didn't work well for Pull Requests
targeting them, because Eval wouldn't run on them with a push event and
thus, Eval in the PR couldn't succeed either. That's now fixed, PRs
towards *any* WIP branch should work correctly.
(cherry picked from commit 55b046451c)
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.
(cherry picked from commit 7763be5a80)
Instead of rolling our own update script which only works for a single
pin, let's use npins. We can then use it for the treefmtNix pin as well,
which was mostly unmaintained, so far.
(cherry picked from commit f7c25f0bf9)
The reason this was a separate shell script was, that this would be
included in multiple workflows separately. But a while ago this had been
changed to a re-usable workflow, so we can just as well inline the
script.
This also allows us to use actions/github-script, which makes for a much
more readable script than the bash script before.
(cherry picked from commit 277f7b998c)
Found using https://github.com/serokell/xrefcheck, which unfortunately
can't trivially be enforced in CI because we also have the manual markdown
files that need post-processing to be valid
Everything gets moved into the `ci/` top-level directory.
We keep behind `maintainers/scripts/check-by-name.sh` and `pkgs/test/check-by-name/pinned-version.txt` as they are going to cause CI errors and confusion until we get all the way through the various channels.
They'll be removed in about a week or so.
This is needed such that in the next commit, we can re-use the same
version from a shell.nix, allowing people to have a guaranteed matching
nixfmt version.
