https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# general
s
This message was deleted.
i
this doesn't quite seem like what you're meant to do, but I've created a new pulumi project with the exact same name & stack name, with a new .yaml config where I've used 
pulumi config set --secret
to set the new token, then had to create a blank index.js with a new resource of the same type. After running 
up
it seems to update the cached token in the remote stack
Without creating a new resource of the same type (or from the same provider) in index.js, it would still try to use the expired token when deleting resources. Having the new resource there meant that the create tasks were executed first, which must have flushed out the expired token
This is fairly poor DX, there must be a better way to interact with remote state
m
You can fetch the config for an existing project using 
pulumi config refresh
i
I did that - and then used 
pulumi config set
to provide newer values, but it still kept trying to use the expired token when deleting resources It was only when I created a dummy resource from the same provider, did the "create" task flush out the expired token from the backend
it would be cool if I could do something like: 1. 
pulumi stack export > state.json
2. manually edit state.json 3. 
pulumi stack import < state.json
oh... it looks like you can! I only knew about step 1
a
Hi @icy-controller-6092 Came across your post while searching for something else. Using the PAT is probably not the best way to do this, since the token expires. We found that the cleanest way to do this was to use 
auth_type="azure-client-secret",
and provide the client ID and client Secret as environment variables.
7 Views
Open in Slack
PreviousNext
Powered by