Skip to content

feat: Add ability to select version of demos/stacks #310

@NickLarsenNZ

Description

@NickLarsenNZ

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.7

The 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 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?
  • Overlap with: 💥 'install' should install 'stable' instead of 'nightly' for operators/demos/etc... #212

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type
No fields configured for issues without a type.

Projects

Status

Done

Status

Done

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions