Repository navigation
feat: Add ability to select version of demos/stacks #310
Description
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:
stackablectl demo in monitoring --release 24.7The default should be the latest stable release.
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 branchConsiderations:
--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
--releasewould remove the need for thestackableReleasekey instacks.yaml.
- Caching - do we need to invalidate the cache if a ref/branch/release is specified?
- Overlap with: 💥 'install' should install 'stable' instead of 'nightly' for operators/demos/etc... #212
Metadata
Metadata
Assignees
Labels
No labels
Activity
NickLarsenNZ commentedon Nov 12, 2024
Not having this is making things really difficult at release time, because the current behaviour:
mainbranch to be stable, which means...nextbranch (which still can't be used by stackablectl without checking out the branch), and then...nextbranch gets mixed with changes that can work for the next release, as well as other changes that break it (eg: image tags that don't yet exist). This confusion could be avoided by using the0.0.0-devtags.nextbranch gets merged - generally breaking the stability promise of themainbranch.Notes:
mainas a stable source, so demos should not either.mainbranch can be treated as dev/nightly/unstable.labrenbe commentedon Dec 6, 2024
We decided to implement the first option
--releasebecause users would typically want to install a stable version (--release devstill allows installing from main) while keeping the overall complexity as low as possible.