When we made the switch from eval.yml to pr.yml we adjusted the labels
job as well - but didn't take into account that we also need to deal
with old PRs at the same time.
Here, we fallback to another API request to get a run for eval.yml when
we can't find one for pr.yml.
When labels.yml is changed the new code is not tested in the PR
directly, yet, because we forgot to add labels.yml to the list of
pull_request files in pr.yml. This lead to one syntax error merged
already.
First data shows, that we're unlikely to need more than 250 within an
hour of regular activity. Once this is empty, we'll need to wait until
the next hourly refill - thus, we'll rather set this a bit higher to be
on the safe side.
The hourly limit is at 5000 and we peaked around 3500, so far. We'll
certainly have to look into reducing API calls, but this should still
work out for now.
When we switched to a scheduled workflow, we also changed these lines to
take the labels directly from the pull request list we iterate over. At
the time it saved us an API request. Meanwhile, we have introduced
throttling to the workflow and this causes a potential race condition:
When the scheduled or manually triggered workflow is kicked off and
empties its reservoir of API requests it might be blocked to wait up
to.. an hour! If this happens, the labels taken from the pull request
list might already be outdated at the time the workflow continues. This
would cause some labels to be reset to their original state, which could
be wrong if, for example, another push has happened in the meantime.
This will have a much bigger impact after the next commit, where *all*
labels are set every time, thus the `before` part must be accurate.
Fetching the current labels right before managing them reduces this risk
significantly.
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.
Note that the code currently assumes that checking >= 2.18 on the
version of an opaque package is enough which works for many things as it
is the fork point of Lix. However, future changes may need to reevaluate
whether it is enough for every check (should more conditional code be
added).
The mock test for building with remote, but distinct target and build
host checks a bunch of internals (how many shell commands are executed,
which ones exactly) that are special cased on WITH_NIX_2_18, so the test
breaks when that is false. I've opted to simply skip the test for now
since the expected call list is very annoying to keep maintained and
updated for multiple versions.
This should fix NixOS configurations with config nix.package.version < 2.18.
To keep it that way, I've added nixos-rebuild-ng with some nixVersions
to passthru.tests that aren't likely to be removed in the short term.
