Problem
flightdeck's current model is oriented around one use case: running a stable, hand-declared fleet of pre-packaged applications - the kind of thing you'd use to run a homelab or a corporate infrastructure built from ready-made services, where the containers themselves are authored by someone else.
Everything reflects that:
targets/*.yml and vaults/*.yml are static files checked into git, hand-authored per target.release.yml's load-yaml-matrix step discovers and deploys to every file in targets/ unconditionally on every release - there's no notion of "some targets exist temporarily."app_refs resolve to published release bundles (owner/repo@tag), i.e. curated app catalogs, not arbitrary images at arbitrary versions.deploy/deploy.py has no teardown path at all - once a target exists, it exists until someone manually deletes its files and cleans up the host by hand.
This doesn't fit a second, genuinely different use case: orchestrating your own test infrastructure - spinning up short-lived test stands to exercise your own containers at arbitrary branches/tags/commits, then tearing them down once the test is done (e.g. one stand per PR, or per feature branch, or on manual trigger).
Proposal
Not fully scoped yet - this needs a design discussion before implementation, since it touches several parts of the pipeline at once. Some threads worth exploring:
- A way to generate a target's manifest (and its vault wiring) programmatically or from a template at trigger time, instead of requiring
targets/{name}.yml to already exist in git before a deploy can happen.
- Deploying arbitrary image refs (branch/tag/SHA) for one's own containers rather than curated release-asset bundles - the vault-per-app model and
env_refs mechanism are probably already agnostic to what the image actually is, so this half may already work; the missing piece is more about generating the target/vault wiring on demand than the image resolution itself.
- The existing per-target
path field (targets/{name}.yml, defaults to ~/flightdeck) already lets multiple targets share one host without colliding - releases/, current, and apps-data are all scoped under it. Worth confirming this is sufficient for running several concurrent test stands on one host, or whether a lighter host-provisioning story is also needed.
- A teardown path: something needs to actually stop containers and prune the release/data directories when a test stand's lifetime ends (PR closed, branch deleted, TTL expired) -
deploy/deploy.py only knows how to deploy today, never how to remove.
Related
This is a genuinely different mode from flightdeck's current one ("stable declared fleet") and would meaningfully broaden what it covers - closing the gap between "run my homelab" and "orchestrate my own test/staging infrastructure" would mean flightdeck could replace a separate tool for the latter entirely.
Problem
flightdeck's current model is oriented around one use case: running a stable, hand-declared fleet of pre-packaged applications - the kind of thing you'd use to run a homelab or a corporate infrastructure built from ready-made services, where the containers themselves are authored by someone else.
Everything reflects that:
targets/*.ymlandvaults/*.ymlare static files checked into git, hand-authored per target.release.yml'sload-yaml-matrixstep discovers and deploys to every file intargets/unconditionally on every release - there's no notion of "some targets exist temporarily."app_refsresolve to published release bundles (owner/repo@tag), i.e. curated app catalogs, not arbitrary images at arbitrary versions.deploy/deploy.pyhas no teardown path at all - once a target exists, it exists until someone manually deletes its files and cleans up the host by hand.This doesn't fit a second, genuinely different use case: orchestrating your own test infrastructure - spinning up short-lived test stands to exercise your own containers at arbitrary branches/tags/commits, then tearing them down once the test is done (e.g. one stand per PR, or per feature branch, or on manual trigger).
Proposal
Not fully scoped yet - this needs a design discussion before implementation, since it touches several parts of the pipeline at once. Some threads worth exploring:
targets/{name}.ymlto already exist in git before a deploy can happen.env_refsmechanism are probably already agnostic to what the image actually is, so this half may already work; the missing piece is more about generating the target/vault wiring on demand than the image resolution itself.pathfield (targets/{name}.yml, defaults to~/flightdeck) already lets multiple targets share one host without colliding -releases/,current, andapps-dataare all scoped under it. Worth confirming this is sufficient for running several concurrent test stands on one host, or whether a lighter host-provisioning story is also needed.deploy/deploy.pyonly knows how to deploy today, never how to remove.Related
This is a genuinely different mode from flightdeck's current one ("stable declared fleet") and would meaningfully broaden what it covers - closing the gap between "run my homelab" and "orchestrate my own test/staging infrastructure" would mean flightdeck could replace a separate tool for the latter entirely.