cut dependence on deployment/check's extraTestScript #770
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
1 participant
Notifications
Due date
No due date set.
Blocks
#224 automated dev-ops workflows
fediversity/fediversity
Reference
fediversity/fediversity#770
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?
so far many of our tests have used a
testScriptvs.extraTestScriptdistinction from shared code indeployment/check/common/nixosTest.nix.we should recheck if some of that might no longer be needed in our post-nixops code.
in case tests would no longer depend on this, they could even be split out so as to live closer to their implementation code, like our service tests.
the
acmenode, the seeming central part of this common logic, when cleared of config does not make testapps-nixositself fail (the seeming simplest test using withenableAcme = true), tho garage will show systemd service failureFailed to start Renew ACME certificate for *.localhost.cutting use of this out itself tho just makes it fall back to
security.acme.defaults.server's default ofhttps://acme-v02.api.letsencrypt.org/directory, which seems to fail statingtimed out resolving 'acme-v02.api.letsencrypt.org/A/IN.it would be nice however to at least shift this type of configuration to our
resources, unifying our handling of this through our data model.