Skip to content

feat: Experimental support for --source in topo templates#273

Open
muchzill4 wants to merge 7 commits into
arm:mainfrom
muchzill4:experimental-templates-source
Open

feat: Experimental support for --source in topo templates#273
muchzill4 wants to merge 7 commits into
arm:mainfrom
muchzill4:experimental-templates-source

Conversation

@muchzill4
Copy link
Copy Markdown
Contributor

Changes

  • Add support for --source in topo templates when TOPO_EXPERIMENTAL_FEATURES=1
  • Test with:
TOPO_EXPERIMENTAL_FEATURES=1 \
    topo templates \
        --source https://raw.githubusercontent.com/arm/topo/refs/heads/main/internal/catalog/data/templates.json
  • Also supports file:// scheme for easier testing locally

muchzill4 added 5 commits May 21, 2026 17:10
Signed-off-by: Bartek Mucha <bartosz.mucha@arm.com>
Signed-off-by: Bartek Mucha <bartosz.mucha@arm.com>
Signed-off-by: Bartek Mucha <bartosz.mucha@arm.com>
Signed-off-by: Bartek Mucha <bartosz.mucha@arm.com>
Signed-off-by: Bartek Mucha <bartosz.mucha@arm.com>
@muchzill4 muchzill4 requested a review from a team as a code owner May 21, 2026 16:15
muchzill4 added 2 commits May 21, 2026 17:17
Signed-off-by: Bartek Mucha <bartosz.mucha@arm.com>
Signed-off-by: Bartek Mucha <bartosz.mucha@arm.com>
Comment thread cmd/topo/root.go
Comment on lines +97 to +101

func experimentalFeaturesEnabled() bool {
const experimentalFeaturesEnvVar = "TOPO_EXPERIMENTAL_FEATURES"
return strings.TrimSpace(os.Getenv(experimentalFeaturesEnvVar)) == "1"
}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should DEVELOPTMENT.md be mentioning this?
Some might say documenting is more maintenance but I think we should document this because of following reasons:

  1. I don't think people will use it at the top of their memory very well
  2. Unless we use it, this is not nice for the code base
  3. it would be good to understand the commitment on using experimentalFeaturesEnabled by documenting it. Lets say an experimental feature was later made an official feature. There would be extra work on testing and cleaning. Would be good to provide a good use case on when experimentalFeaturesEnabled should be introduced when we already have a PR system with e2e testing.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe the experimentalFeatureEnabled part of the PR should be a separate PR with the DEVELOPMENT.md change?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants