The current approach runs e.g. `nix-build nixos/release.nix -A tests.installer`,
which is a no-op because `tests.installer` is a set of sets of
derivations (e.g. `tests.installer.simple.x86_64-linux`).
Use `nixosTests` instead, which doesn't have this extra nesting.
By switching to the tools bundled within nixpkgs we can provide a much
more "pure" development environment that doesn't randomly change over
time.
Previously we would be using the latest and greatest version of the
formatting and linting tools while our development environment only
offered whatever was in the (old) nixpkgs pin. Nowadays we have all the
tools we need in nixpkgs and can thus use those instead. By following
nixpkgs more closely we can make sure to make use of those tools in this
project as well. Hopefully removing the "yearly churn" of doing big
migrations.
For the meantime I allowed the upper case acronyms check (and a few
other minor lints) in the clippy configuration. This will allow a
smoother transition towards the newer clippy code that is decoupled from
the actual linting changes.
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.
Some of the information in the README is outdated, such as the sections
detailing the privileges of known users (everybody is now a known user).
The only distinction made is between that of trusted users and everybody
else. Trusted users gain an additional host to run builds and tests on:
x86_64-darwin. Everybody else is locked to x86_64-linux and
aarch64-linux.
With the removal of all mentions of "known users", the
`config.{extra-,}known-users.json` files have also been removed. This
change will require coordination with the infrastructure repo [1] --
namely, a PR removing references to these files (otherwise, I imagine,
deploys will fail).
Something Graham has mentioned a few times is how he wants to decouple
ofborg from his persona. Thus, `@ofborg` is now used in place of
`@GrahamcOfBorg` everywhere possible (it is still possible to use
`@GrahamcOfBorg`, so it has not been removed from the codebase at this
time).
[1] https://github.com/ofborg/infrastructure
Include tools for generating the known user
list, and a thing to allow me to keep secrets
out of the main config while still keeping
almost exactly my config in version control
nearby.
The old design of the parser treated all whitespace the same and
mandated that `grahamcofborg` (plus the `@`) be the first token in the
text. This allowed for some ridiculous but command calls:
grahamcofborg build foo
bar
baz
This used to become a build instruction for foo, bar, and baz. After
this change, it is just an instruction for building foo. This allows
for comments for people to be intertwined with comments for the bot:
grahamcofborg build foo
Let's see what happens!
Before this would unintentionally become a build instruction for
`foo`, `Let's`, `see`, `what`, `happens!`, and is now only going to
build `foo`.
Additionally, this comment would do nothing:
Let's see what happens!
grahamcofborg build foo
Or a more real case where people expected this to work:
/cc grahamc for ^^
GrahamcOfBorg eval
This will continue to not produce a build instruction, because
grahamcofborg must be the first word of a line:
foo bar grahamcofborg build foo
Note: I've removed `@`s from all usernames to avoid accidental email.
