There's been a few deadlock problems with Nix 2.3, as discusssed in the
commit message of https://cl.tvl.fyi/c/depot/+/12334.
However, since the fork nothing prevents us from dropping the Nix 2.3
requirement for CI.
Change-Id: Ib00603597dbc11dc1b619fdeee264d7d519eaa02
Reviewed-on: https://cl.snix.dev/c/snix/+/30108
Autosubmit: Florian Klink <flokli@flokli.de>
Tested-by: besadii
Reviewed-by: Ryan Lahfa <masterancpp@gmail.com>
As soon as you pass in an already-instantiated nixpkgs version, it will
cause nixpkgs.hostPlatform etc. to be not applied.
This means it's impossible to describe the architecture of a VM closure
you're deploying, and have it deviate from the machine you're evaluating
from, making it quite hard to deploy that x86_64-linux machine from
aarch64-linux (where I'm writing this commit message from).
Drop explicitly passing in nixpkgs.path, and set nixpkgs.hostPlatform
explicitly for all remaining system configurations in the repository
where not already set.
Change-Id: Ie2a596e0826da54674b4f02fcd8fed3569fee0a4
Reviewed-on: https://cl.snix.dev/c/snix/+/30104
Autosubmit: Florian Klink <flokli@flokli.de>
Tested-by: besadii
Reviewed-by: Ryan Lahfa <masterancpp@gmail.com>
Normal agents can easily go from 16 -> 24 (proportionally to whitby, this makes
more sense).
I've kind of randomly decided to label 6 agents as large ones. We will filter
things like eval, or building tvix tests (until b/431 is resolved).
Change-Id: Ib38d2c56410c2ad9d86a01546c00192f87274bb3
Reviewed-on: https://cl.tvl.fyi/c/depot/+/13121
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Removes whitby DNS records and other related configuration that is no longer
required now that whitby is gone.
whitby served us well. RIP.
This resolves b/433.
Change-Id: I56fe6f88cde9112fc3bfc79758ac33e88a743422
Reviewed-on: https://cl.tvl.fyi/c/depot/+/13117
Reviewed-by: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
Autosubmit: tazjin <tazjin@tvl.su>
This turns off almost all of the lights. The server will be decomissioned on
2025-02-05. Until then we can keep running the Buildkite builders there for
extra capacity.
Stuff that was left in the whitby config has been migrated to nevsky.
This relates to b/433.
Change-Id: I84953e9d5e912f75b8884cb9d8edd5a1b7d5c85d
Reviewed-on: https://cl.tvl.fyi/c/depot/+/13095
Reviewed-by: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
... that is then promptly enabled on nevsky.
Change-Id: Ie51037cec810bb7f81099a67ebd2581dcf710bd5
Reviewed-on: https://cl.tvl.fyi/c/depot/+/13093
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
These are the postgres-database using services.
Change-Id: I4e8d854e798d85e1b14bfa78aae8827ac0881c7d
Reviewed-on: https://cl.tvl.fyi/c/depot/+/13092
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Runs the Gerrit instance with the same config as previously on whitby. Data has
been migrated manually using `tailscale file` (which worked surprisingly well).
Change-Id: I6e85f932c834b2c36fc40327ae081ee396c5e16f
Reviewed-on: https://cl.tvl.fyi/c/depot/+/13077
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Same as whitby, with the difference that there is now a listener on the
tailnet (just in case).
Change-Id: I841b2283112a0fea54f3c35a2dc4d2dd393b2612
Reviewed-on: https://cl.tvl.fyi/c/depot/+/13071
Reviewed-by: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
All the postgres-dependent services are going to migrate here.
Change-Id: Ie2a25395f6fe6e3c9f7a45f21cf90c635e208cdd
Reviewed-on: https://cl.tvl.fyi/c/depot/+/13070
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Apparently I set this up manually before, and failed to commit it ...
Change-Id: I550a2cd9e1fcc8b508bafc2fd06ddab2a915b597
Reviewed-on: https://cl.tvl.fyi/c/depot/+/13060
Autosubmit: tazjin <tazjin@tvl.su>
Reviewed-by: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
This is no longer needed; Nixery is now served by bugry.
Change-Id: Idd072505c4da1e6af636224e092b6fb21eff9250
Reviewed-on: https://cl.tvl.fyi/c/depot/+/13001
Reviewed-by: sterni <sternenseemann@systemli.org>
Autosubmit: tazjin <tazjin@tvl.su>
Tested-by: BuildkiteCI
Running Nixery on bugry is much more cost efficient (better traffic economics
than on a cloud provider, and Nixery is mostly a traffic-heavy service), and
frees up my Yandex Cloud credits for adding another builder.
Change-Id: Id6c8c76b28a5ce13cc8b743ad6e72fffd19353fb
Reviewed-on: https://cl.tvl.fyi/c/depot/+/12997
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Autosubmit: tazjin <tazjin@tvl.su>
I thought this was enabled and got confused when deploying ... cache should
always be enabled on machines that don't build themselves.
Change-Id: Ie52b27c44db4c26387b05553dbe36f7693628e89
Reviewed-on: https://cl.tvl.fyi/c/depot/+/12993
Autosubmit: tazjin <tazjin@tvl.su>
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Configures an experimental setup for a builderball-based public cache.
This cache only includes the two build machines (whitby & nevsky), for the time
period where both of them exist simultaneously.
The idea is this:
All participating hosts run a harmonia binary cache locally (whitby already
does). They then run builderball instances pointing at each other's harmonia
caches (through dedicated public hostnames).
When a request comes in, the first matching cache address is returned and Nix
will substitute from there.
Change-Id: Ia7d5357fd5e04f77b460205544fa24e82b100230
Reviewed-on: https://cl.tvl.fyi/c/depot/+/12975
Autosubmit: tazjin <tazjin@tvl.su>
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Otherwise pushes to Github from CI will fail.
Change-Id: Ib3eb3165577cb98c5a7d5f2055b09dbf118da6c3
Reviewed-on: https://cl.tvl.fyi/c/depot/+/12994
Autosubmit: tazjin <tazjin@tvl.su>
Reviewed-by: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
Adman (the hoster) have not provided an ETA for native v6 on bugry yet, so we
establish a public v6 connection through nevsky for now.
In traffic flows going West->East the overhead is minimal (a few ms), though I
guess it might be worse if you're in the middle (Yekaterinburg or something).
The prefix was chosen by the bugry public v4 address encoded in hex, and
appended to the nevsky prefix.
Change-Id: I133622c17bd02eade0a6febc6bdf97f403fed14c
Reviewed-on: https://cl.tvl.fyi/c/depot/+/12974
Autosubmit: tazjin <tazjin@tvl.su>
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
This is just a carbon-copy of other machine configurations for now. The plan is
to switch this over to sixos, but I have to get a sane NixOS setup first because
this still requires a lot of experimentation (and stuff to be built *on* this
machine, since it's the fastest one we have).
Change-Id: I2e55e63ed5192eb748855999bb87d43498e706fc
Reviewed-on: https://cl.tvl.fyi/c/depot/+/12971
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
The copy&paste from the documentation didn't work ...
Change-Id: Ic894356354d6ac2b66562da5aa89590cd94ae347
Reviewed-on: https://cl.tvl.fyi/c/depot/+/12705
Reviewed-by: tazjin <tazjin@tvl.su>
Autosubmit: tazjin <tazjin@tvl.su>
Tested-by: BuildkiteCI
Harmonia is, ostensibly, faster and better and, most importantly, not a giant
pile of wonky Perl.
I've tested locally that Harmonia works with Nix 2.3 (on both ends), so I think
we should be good to go here.
We have a vendored copy of the upstream module for now. We need to fix Nix 2.3
compatibility in upstream for the module, but the service itself works fine.
Change-Id: I3897bb02b83bd466b6fe7077c05728ac49ea4406
Reviewed-on: https://cl.tvl.fyi/c/depot/+/12517
Tested-by: BuildkiteCI
Autosubmit: tazjin <tazjin@tvl.su>
Reviewed-by: sterni <sternenseemann@systemli.org>
