This message was deleted.
# general
s
This message was deleted.
👍 1
w
You could be to create a new stack for this preview testing:
pulumi stack init test-preview
And then switch to the deployment stack
pulumi stack select real-stack
That said, this really isn’t necessary since even in the case where there are existing resources, pulumi is processing the entire pulumi application to check for any changes.
a
Thanks a lot for the suggestions, Mitch! In this case I was hoping to avoid checking the active stack entirely since, at least in my case, doing so requires having access to AWS credentials. I was hoping to have the pulumi code checked for logical errors within GitLab CICD pipelines for unprotected branches (e.g. a feature branch which wouldn't actually be 'updated' until it was merged into the master). But if I understand you correctly, this will not be avoidable 😕
w
OK. so if I understand correctly, the goal is to avoid having to configure AWS credentials to do this code check. I don’t know if this helps, but if you are trying to catch typos/syntax errors/usage errors (e.g. using a wrong property name), then you can run
pulumi preview
with out the cloud credentials in place, and it will throw a found syntax/usage error before trying to talk to AWS. If the syntax/usage is fine, it will then still fail but with an “AWS Provider: no valid credentials sources” type of error which you could detect and not get upset about.
a
That's a nice tip. Do you have any ideas about how that can be done? I assume it would involve running
pulumi preview
in bash and then, when the error is raised, somehow parsing the output to determine if it failed due to syntax/usage (which would then be caught) vs something else (which would be 'allowed'). I've personally never seen a bash script do something like this (although I am certainly not a bash-super-user 😅 )
w
It’s doable, but probably clunky. I wonder if this might be an opportunity to use the automation api.
a
Hello again @witty-candle-66007, thanks again for the continued support! Actually, these are the same links that originally sent me on my CICD journey 🙂