Examples (competing ideas, in no particular order)
stackablectl demo in monitoring # latest stable. Currently this deploys manifests from `main`
# Enforce a particular release
stackablectl demo in monitoring --release 24.7
stackablectl demo in monitoring --release dev
# Take any committish (stackableRelease derived from stack.yaml at that version)
stackablectl demo in monitoring --ref abcdef7
stackablectl demo in monitoring --ref release-24.7
# Or, enforce a branch (because the HEAD is what should be working. Random commits might cause surprises)
stackablectl demo in monitoring --branch release-24.7 # but must be a branch
Considerations:
--ref (Committish), or --branch (and check that it is a branch), or --release (we need to derive the ref).
We can work out the operator release, because at that version
We should ideally go with the most flexible (--ref), unless we cannot derive the release.
⚠ There will still be hard coded refs in the stack/demo yamls, as well as scripts. This can lead to broken demos.
Specifying --release would remove the need for the stackableRelease key in stacks.yaml.
Caching - do we need to invalidate the cache if a ref/branch/release is specified?
~Once demos are versioned per release (see sub-issue)~ DONE, we should be able to select which demo/stack version to install.
Suggested option to add:
The default should be the latest stable release.
Examples (competing ideas, in no particular order)
Considerations:
--ref(Committish), or--branch(and check that it is a branch), or--release(we need to derive the ref).--ref), unless we cannot derive the release.--releasewould remove the need for thestackableReleasekey instacks.yaml.