I didn't like r-ryantm "authoring"; so I changed that to "created"
earlier. Arguably, using "opened" is more consistent with what is
actually checked and can consistently be used for both.
The by-name check would previously be green when the
`pkgs/by-name/README.md` file was changed. This would still not mean the
maintainer was able to merge the PR, because there'd be no maintainer
for that file, but the feedback was not 100% accurate.
This allows committers to approve PRs with additional, optional nits
that the author-maintainer can either address or merge immediately
without these changes.
It also allows committers to approve a PR for merge, while still waiting
for other maintainers to give their feedback - they can then merge the
PR directly instead of passing it back to the committer.
All other conditions equal, there is no reason to prevent maintainers
from backporting changes to their packages. Maintainers are probably in
the *best* position to tell whether a certain change is backportable or
not - because they know the package well.
This supports AND on the first and OR on the second level, which is
needed for some follow up work like backports, approval based merges or
trusted maintainers.
Over the last couple of months we have been migrating a lot of the old
bash code to JavaScript, which is supported in GitHub Actions via
`actions/github-script`. This change documents a "manual ratchet check"
for this migration - new code should only be introduced as JavaScript
and not as Bash. This will help us to eventually succeed with the
migration and ensure quality and maintainability.
We are migrating to JavaScript, because:
1. Using JavaScript is GitHub's [recommendation] against injection attacks.
Using `actions/github-script` has first-class support for the event
context and does not require to resort back to environment variables in
most cases. When environment variables need to be used, these are
accessed via `process.env`, without a risk for accidental injections.
Using `actions/github-script` is also recommended in a recent
[survey] of open source supply chain compromises:
> Finally, since two out of three compromises were due to shell injection,
> it might be safer to use a proper programming language, like JavaScript
> with actions/github-script, or any other language accessing the context
> via environment variables instead of YAML interpolation.
2. Handling even environment variables in Bash safely is almost
impossible. For example arithmetic expressions cause arbitrary code
execution vulnerabilities. While a lot of contributors are somehwat
familiar writing Bash code for builders, writing *safe* Bash code for
CI is a very different matter. Few people, if any, know how to do
this.
3. GitHub Action's security model is quite unintuitive and even if some
code runs with trusted inputs today, it may later be used in a more
exposed context. Instead of making judgement calls about language
choice case by case, a clear policy helps writing things defensively
from the beginning.
4. We have developed a framework around our github-script based tools in
`ci/github-script`. This provides a local `nix-shell` environment
with the right dependencies and a local runner for these scripts for
quick testing, debugging and development. No matter, whether you're
developing a new feature, fixing bugs or reviewing a PR - this allows
much quicker verification of the scripts, *without* running
everything in a fork or test organization.
5. This framework also provides helpers for challenges that come up with
GHA. One example is rate-limiting, where we have a helper script that
will handle all rate-limiting needs for us, preventing us from
running out of API calls and thus breaking CI entirely. We can only
use these tools consistently, if we consistently use JavaScript code.
6. Using JavaScript allows us to handle JSON natively. Using
`octokit/rest.js` provides first-class integration with GitHub's API.
Together, this makes these scripts much more maintainable than
resorting to `gh` and `jq`.
[recommendation]: https://docs.github.com/en/actions/reference/security/secure-use#use-an-action-instead-of-an-inline-script
[survey]: https://words.filippo.io/compromise-survey/
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.
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 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.
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.
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.
