publishing "testing" version of modules
When developing module we would like to see the fallout of our changes, but they only way to have stacks use the Work in progress (WIP) module version is to use a local path, or coping the whole module into the stack and use it as a sub-module, with even more complexity added if the module is use in another published module.
Our proposed fix would be a WIP tag we can add when publishing a module, that would prevent an stack from applying a stack using a WIP module version, and module versions with the WIP tag can be updated. And finally a way to remove the WIP tag to lock the module version so it will be reported as the newest version and used by tracked runs.
- Problem
Log in to comment and vote
Comments4
Jonah Kowall
Jul 12
Thanks for the suggestion. Today you can approximate this with pre-release version numbers consumed explicitly by downstream stacks, tag-driven release flows via push policies, and marking bad versions to block consumption: https://docs.spacelift.io/vendors/terraform/module-registry. Given limited demand since filing, I’m closing this rather than keeping it open indefinitely. If pre-release flows are a recurring need for your team, let us know how the current mechanisms fall short.
Black Breeze
May 10, 2025
Thank you for bringing up this valuable feature request. At Spacelift, we understand the importance of being able to preview and test new Terraform module versions before they are officially published. We’ve explored several possible approaches to meet this need, each with its own benefits and trade-offs. We’d appreciate your feedback on which approach(es) best align with your workflows and requirements:
1. Semantic Versioning Pre-release Tags
Approach:
Use standard semantic versioning pre-release identifiers to clearly distinguish preview versions. Examples include versions like 1.2.3-preview.1, 2.0.0-beta, or 1.3.0-rc.1.
Advantages:
Compatible with Terraform’s existing version selection and registry protocol.
Straightforward and familiar method (common in other software ecosystems).
Terraform automatically prevents accidental use in production since pre-release versions must be explicitly specified.
Potential Issues:
Preview versions would be visible.
Possible clutter in the registry version list if many previews are published.
2. Separate Preview Endpoint or Namespace
Approach:
Create a completely separate preview registry endpoint or namespace. For example, preview modules would be hosted at preview.spacelift.io/<namespace>/<module>, clearly separating preview modules from stable ones.
Advantages:
Strong separation reduces the risk of accidentally deploying preview versions to production.
Easier version management and cleanup (keeping previews isolated).
Potential Issues:
Users must manually update their Terraform module source configuration to switch between preview and stable endpoints, potentially causing friction.
Adds complexity to managing and maintaining multiple endpoints.
3. Authenticated or Scoped Previews
Approach:
Offer preview module versions through the existing module registry but restrict their visibility and accessibility based on user authentication. Users with appropriate permissions can access and test these preview versions, while others would see only stable, published versions.
Advantages:
No need to change Terraform configuration—preview and stable modules share the same address.
Better security and visibility control: previews are only accessible to specific users or teams.
Potential Issues:
Increased complexity in access management and permissions handling within the registry.
Potential confusion if unauthorized users inadvertently attempt to access restricted previews.
4. Branch or Commit-Based Ephemeral Versions
Approach:
Automatically generate preview versions tied directly to specific Git branches, pull requests, or commits. Versions could be named like 0.0.0-featureX.sha123abc, indicating clearly their source branch or commit.
Advantages:
Provides a highly flexible, CI/CD-friendly way to continuously preview module changes.
Allows rapid iteration and testing without manual versioning overhead.
Potential Issues:
Could significantly expand the module version list, requiring careful pruning and cleanup strategies.
Introduces additional complexity into version management and naming conventions.
Your feedback matters:
Which approach(es) resonate most strongly with your workflow and why?
Would a combination of these approaches better meet your needs? If so, how would you see that working?
Are there particular concerns or considerations we’ve missed here?
We appreciate your input—it will help shape the direction we take to best support your Terraform workflows!
Chocolate Pickle
Sep 3, 2025
Hey sorry this took a while for me to get back too, it got buried in my inbox.
I think we 4(Branch or Commit-Based Ephemeral Versions) would work the best with our workflows, I wonder would it be difficult to have them auto expire so our CI could mark a new version on commit X but its only use-able for the next 2-3 days. With the advantage that the user will not have to go back to cleanup unused Ephemeral versions.
I will keep a close eye on this feature request as we believe it would greatly improve productivity when working on modules.
Blush Frog
Feb 10
Hello Marcin,
Not sure if this conversation is tracked anymore, but in our older environment we’re looking to migrate off of we’ve used your option 1, semver pre-release tags, with most being a -b<datetime> added onto the end. We’d be alrigth with the branch-based approach as discussed in comments, here, as well, though we wouldn’t want these in-development versions to disappear without some user approving such a thing.