We use the admin stack pattern with for_each over auto-discovered config files. When a PR introduces a new config (i.e., a net-new stack), the PR gets no plan preview because the stack doesn't exist yet. Reviewers merge blind.
Post-merge automation works β trigger policies handle auto-triggering newly created stacks. But pre-merge plan visibility for stacks that don't yet exist has no platform-native solution.
Adding new infrastructure is when plan previews are most valuable. Modifying existing stacks has full visibility today. Creating new stacks has zero visibility until after merge.
When an admin stack's proposed run on a PR shows new spacelift_stack resources would be created, Spacelift should automatically run speculative plans for those new stacks using the PR branch and post the results as PR comments.
Suggested UX:
Opt-in setting on the admin stack (e.g., "Enable speculative plans for new stacks discovered in PRs").
After the admin stack's proposed run completes and shows new spacelift_stack resources, Spacelift triggers speculative plan-only runs for those stacks using the PR branch.
Results appear as PR comments labeled distinctly (e.g., "Speculative plan for new stack stack-name").
Speculative stacks are ephemeral and are cleaned up when the PR is closed or merged.
The only alternative is external automation (e.g., a CI job that detects new config files, creates temporary stacks via spacectl, triggers plans, posts comments, and cleans up). This duplicates discovery logic that already exists in the admin stack and is disproportionately complex for something Spacelift is positioned to handle natively.
Please authenticate to join the conversation.
π In Review
π‘ Feature Requests
About 21 hours ago
Get notified by email when there are changes.
π In Review
π‘ Feature Requests
About 21 hours ago
Get notified by email when there are changes.