Yeah.. can't get over this hurdle.. genuinely don'...
# automation-api
Yeah.. can't get over this hurdle.. genuinely don't know what I could do any longer to get past it.
Copy code
λ ts-node automation.ts
CommandError: code: 4294967295
 stderr: error: decrypting secrets: passphrase must be set with PULUMI_CONFIG_PASSPHRASE or PULUMI_CONFIG_PASSPHRASE_FILE environment variables


    at Object.createCommandError (c:\<path>\node_modules\@pulumi\pulumi\x\automation\errors.js:71:17)
    at ChildProcess.<anonymous> (c:\<path>\node_modules\@pulumi\pulumi\x\automation\cmd.js:63:40)
See code in post above for source, and in the thread for the automation.ts code as well.. Basically I'm running automation on top of a preexisting standard pulumi-cli set of stacks in a project. Previously, I got the message when I failed to set AZURE_KEYVAULT_AUTH_VIA_CLI to true - but now I've both got it in the environment I'm executing in AND the envVars of the LocalWorkspace settings. Also - the CommandError: code: is a bit weird because there are quite a lot of hits for that exact code.. which is really weird.. and that code returns results relating from electron stuff to .msp upgrades of adobe software to IIS stuff.. The most useful result was the IIS one which has this as the title:
ERROR_FILE_IN_USE msdeploy.exe failed with return code: 4294967295
- could this be a filesystem issue somehow?! Using pulumi
if it helps.
One hint seems to be that automation overwrote my existing Pulumi.yaml.. that's not right is it? Same name + runtime, but lost the description, config and backend stuff
Yup - that was it - turns out that my declaration of Pulumi.yaml would be overwritten entirely and disregarded by automation, so if I wanted to use it, I had to import it myself:
const currentProject = yaml.load(fs.readFileSync("./Pulumi.yaml"))
and the LocalWorkspace:
..projectSettings: currentProject..
Still getting the error code 4294967295 though - and I have a feeling it might be due to my absolutely massive stack output.. it contains all the stack resources and all the configuration elements used to create it, including temporary configuration operations to create the final result..
I.e. my design decision at the moment is - it doesn't hurt to just throw it in the output 😄.. Guess I might be wrong
You should not need to do this. If you just set
to the directory that contains your pulumi yaml, it will pick it up automatically.
well - it didn't. it overwrote the already existing Pulumi.yaml, even when i did not have any
If you specified
without explicit
then this behavior would be a bug and we should fix it. If you have a repro, please share or file an issue:;labels=kind%2Fbug&amp;
Bug raised: Includes link to repo for reproduction.