[solved] PULUMI_ACCESS_TOKEN seems to have stopped...
# general
f
[solved] PULUMI_ACCESS_TOKEN seems to have stopped working in our github CI . I tried swapping to a new token to resolve it with no success. Nothing seems to have changed on our end . using pulumi/actions@v3 and pulumi/setup-pulumi@v2 in github actions
Copy code
getting secrets manager: passphrase must be set with PULUMI_CONFIG_PASSPHRASE or PULUMI_CONFIG_PASSPHRASE_FILE environment variables
e
Although suprising your managing to hit this with PULUMI_ACCESS_TOKEN? That suggests your using the pulumi service, and should use that as the secret manager.
f
yes we are using the hosted version
to pin to an earlier version it looks like i can use
pulumi/setup-pulumi@v2
and just
run: pulumi up --stack ...
. Otherwise I'm stuck with whatever version
pulumi/actions@v3
gives me
pinning to 3.30.0 didn't work. so i'm trying to pin to what's in our yarn.lock (3.3.0)
e
Are you sure 3.30.0 didn't work? We changed handling of CONFIG_PASSPHRASE in 3.32 and 3.32.1, but if 3.30 isn't working its nothing to do with those env vars.
f
i think 3.30 didn't work cause I had removed the PULUMI_CONFIG_PASSPHRASE: "" line in my github action. but i added that and made it 3.3.0 and now its working. so i can attempt to upgrade again
I want to unblock my team first though 😃
e
PULUMI_CONFIG_PASSPHRASE: ""
If your using the service why are you also using the passphrase secret manager? Just let the service do it
f
dont you have to set PULUMI_CONFIG_PASSPHRASE to an empty string when using the service secret manager?
huh yeah my secrets_providers is 'passphrase' and i'm wondering if who-ever set this up just set the passphrase to an empty string...
huh... prod stack is using awskms. staging stack is passphrase and deleted dev stack is using api.pulumi.com . this is very messed up
swapping my staging to awskms and pushing the changes it made has resolved it. thanks for your help!
e
dont you have to set PULUMI_CONFIG_PASSPHRASE to an empty string when using the service secret manager?
Nope, you just want to leave it unset if using the other secret managers. What broke you is we changed 3.32 to treat unset and "" as the same. People kept trying to 'unset' it by doing PASSPHRASE="" in their shell. Plus who wants an empty string as a passphrase. Glad the pointers got you sorted out 🙂