Contract-test our interaction with NixOps4 #90
Labels
No labels
0 points
0.5 points
1 point
13 points
2 points
21 points
3 points
34 points
5 points
55 points
8 points
api service
blocked
component: fediversity panel
component: nixops4
documentation
estimation high: >3d
estimation low: <2h
estimation mid: <8h
infinite points
productisation
project-management
question
role: application developer
role: application operator
role: hosting provider
role: maintainer
security
technical debt
testing
type unclear
type: bug
type: deliverable
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#90
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
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?
NixOps4 is still under heavy development, and we need to make sure that when we're interfacing with it, our code doesn't break when updating NixOps4. Having our own test guards against accidental backwards-incompatible changes on the NixOps4 side that will break our deployments at time of use. Instead we will get notified at time of dependency update by a failing test.
Thinking about it, we probably want to have our entire deployment tested against a simulated environment to exercise all the code paths currently in use...
You can use the nixops4-nixos VM test as a reference. (permalink)
Ideally we also make use of the fact that these tests are modules, so we can factor out common bits if that makes sense.
Probably the
deployernode can be factored into anixops4-nixos.modules.nixosTests.test-inframodule or something. Maybe also other things. Options can be added to controltestScriptand whatnot, as needed.closing in favor of #276