Unflakify deployment tests #449
No reviewers
Labels
No labels
api service
blocked
bug
component: fediversity panel
component: nixops4
documentation
estimation high: >3d
estimation low: <2h
estimation mid: <8h
productisation
project-management
question
role: sysadmin
security
technical debt
testing
type unclear
type: key result
type: objective
type: task
type: user story
user experience
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: Fediversity/Fediversity#449
Loading…
Add table
Reference in a new issue
No description provided.
Delete branch "Niols/Fediversity:unflakify-tests-3"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR builds on top of #447 and #448. Since these might be rejected, there will be some changes needed for this PR as well. Let's see how the discussions go in #447.
In the meantime, @fricklerhandwerk, would you mind (in)validating the core idea of this PR? You only need to look at
7cf43c4041
, really.mkFlake
hack to own file 9090e0b952mkFlake.nix
git-hooks
from npins/flake.nix
7cf43c4041deployment/flake-part.nix
for what it's worth, i don't currently have strong opinions on this, so i'll leave it to y'all
LGTM conceptually! More comments on mkFlake in the respective PR.
@ -136,2 +136,3 @@
## instance by allowing to grab things directly from the host's store.
with subtest("Override the lock"):
with subtest("Override the flake and its lock"):
deployer.succeed("cp ${config.pathFromRoot}/flake-under-test.nix flake.nix")
It may be worth noting in a comment here that we're otherwise using the entire repository as is. Otherwise it's slightly too magical when you try to trace it through in your head.
Fair enough. I have added a comment explaining this. (Only locally on my machine for now, as I don't want to overwhelm our CI.)
CI-killing comments...
Yeah, frustrating! It will come as soon as I rebase after the merge of #448.
@ -138,4 +139,3 @@
deployer.succeed("""
nix flake lock --extra-experimental-features 'flakes nix-command' \
--offline -v \
--override-input flake-parts ${inputs.flake-parts} \
Arguably we don't need flake inputs here at all as we can pass store paths via
sources
here, which means we don't need flakes at all at the project level (unless flake-parts wants a root flake to do its thing). Not saying we need to pull through with that now, just trying to separate accidental from essential complexity.Is this comment different from #449 (comment)?
I thought it was but seems like it's not.
@ -135,3 +135,3 @@
## NOTE: This is super slow. It could probably be optimised in Nix, for
## instance by allowing to grab things directly from the host's store.
with subtest("Override the lock"):
with subtest("Override the flake and its lock"):
Regarding the slowness -- do we even need the flake-under-test to have flake inputs? If we make the right store paths available in the test VM (e.g. by mounting the host store) we may as well get the sources in that flake-under-test from npins and save ourselves the lock override.
Well in my head we were aiming to have our
flake.nix
without inputs, grabbing everything from npins. This would then also give this for free: ourflake-under-test.nix
files would indeed be simple, grab everything from npins as well, and we would not have this slowness anymore.Of course, we can still have our
flake-under-test.nix
have no flake inputs and grab everything from npins, whileflake.nix
still has some regular flake inputs, but then we have the problem of aligning the npins and flake dependencies.I think we shouldn't tackle this in this PR. We should have a subsequent PR showing a way to grab
nixops4
andnixops4-nixos
from npins, and using that to replace the flake inputs of theflake-under-test.nix
files, but maybe also from theflake.nix
file.Yes agreed. And I didn't imply we should do anything about that in this PR.
git-hooks
from npins #448git-hooks
from npins #448aba96a84d5
toe0a4d652b4