-
Notifications
You must be signed in to change notification settings - Fork 251
Clarify stack policy timing in CrossGuard documentation #15367
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Your site preview for commit 52f92ba is ready! 🎉 http://www-testing-pulumi-docs-origin-pr-15367-52f92bae.s3-website.us-west-2.amazonaws.com. |
- During `pulumi preview`: Stack policies run after the preview completes, using whatever output values are already known from previously provisioned resources. Since no new resources are actually created during preview, stack policies are most useful in this context for catching violations before any provisioning occurs. | ||
- During `pulumi update`: Stack policies run after all resources have been provisioned, but before the update operation completes. This means non-compliant resources may already be created by the time the policy violation is detected. | ||
|
||
For this reason, stack policies are most effective when used with `pulumi preview` to identify issues before actual resource provisioning. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there are some subtle tradeoffs here. Preview won't necessarily resolve all outputs, so the policy may be evaluating a different set of properties depending on the operation. However, as you note, preview gates all changes to the stack.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you give me an example of where an output might not be resolved in a preview if a resource was already provisioned in a pulumi up
? (That's what I was trying to communicate there, so if that was not clear I will reword it.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First one that comes to mind is the docker buildx provider, which won't actually build the image during preview. There are probably a few other resource types where the state is expected to change at runtime often. It's a minor detail, and probably better to be prescriptive with advice that is right for the vast majority of cases.
Add detailed explanation of when stack policies execute during preview vs update operations. Clarify that stack policies are most useful during preview operations since they can catch violations before actual resource provisioning occurs. Fixes #11508 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
52f92ba
to
5f57212
Compare
Your site preview for commit 5f57212 is ready! 🎉 http://www-testing-pulumi-docs-origin-pr-15367-5f57212e.s3-website.us-west-2.amazonaws.com. |
Add detailed explanation of when stack policies execute during preview vs update operations. Clarify that stack policies are most useful during preview operations since they can catch violations before actual resource provisioning occurs.
Fixes #11508
🤖 Generated with Claude Code