No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

This looks like <https://github.com/pulumi/pulumi/issues/9541>

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.

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)

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.

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 :smiley:

&gt; PULUMI_CONFIG_PASSPHRASE: ""
If your using the service why are you also using the passphrase secret manager? Just let the service do it

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  <http://api.pulumi.com|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!

&gt; 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 :slightly_smiling_face: