This is perhaps a bit controversial. The only acronym that I allowed is
the NixOS acronym all the others are required to follow the clippy
naming conventions.
The current darwwin builder is reset very, very frequently (mostly due to its
storage constraints necessitating it), so there's much less of a reason to limit
the people who can utilize it. (Enabling it for everybody will also guarantee
more frequent resets, as well.)
However, it is kept as an option so that it can be re-enabled some time in the
future, if anything were to happen.
* If the sha we're operating on already has checks beginning with the old
`grahamcofborg-` prefix (e.g. someone just used `@ofborg eval`, `@ofborg build`,
or `@ofborg test`), continue using that prefix.
* If the sha we're operating on doesn't have any checks beginning with the old
`grahamcofborg-` prefix, use the new `ofborg-` prefix. This will take effect on
all new PRs immediately, and after a force-push for all existing PRs.
There are some out of pkgs/development/ocaml-modules paths like
pkgs/applications/networking/jackline which would be nice, but
ultimately maintaining that list would be a bit of a nightmare.
This fixes the `Unable to process command
'::add-path::/nix/var/nix/profiles/per-user/runner/profile/bin'
successfully.` errors (this was deprecated by GitHub).
Also fix alignment, to ease copy-pasting.
It was lost in the `Not you: team` change. It probably makes sense to
keep this documented as people involved in this project might change
over time and sometimes memory can also be blurry :)
Nixpkgs requires Nix 2.2 or greater to evaluate as of
96795314de,
and Travis does not appear to support this version yet, causing CI to
report failures on probably-good PRs. This can be reverted later on down
the line if we decide to have both GitHub Actions and Travis for
redundancy.
The Stream implementation for consumers was changed to include the
channel. Should be the last api change since it's released now.
impl Stream for Consumer {
type Item = Result<(Channel, Delivery)>;
}
This either indicates it's most likely either a tree-wide change,
staging-next merge or just a pull request with an incorrect target
branch. For none of these cases are usually relevant for specific
package maintainers.
Seems to cause an issue with the executors somehow.
thread 'main' panicked at 'cannot run an executor inside another executor', <::std::macros::panic macros>:2:4
Jörg Thalheim
Alyssa Ross
adisbladis
Luke Granger-Brown