Yeah.. can't get over this hurdle.. genuinely don'...
# automation-api
b
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
 stdout:
 stderr: error: decrypting secrets: passphrase must be set with PULUMI_CONFIG_PASSPHRASE or PULUMI_CONFIG_PASSPHRASE_FILE environment variables

 err?:

    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
2.23.2
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
l
You should not need to do this. If you just set
workDir
to the directory that contains your pulumi yaml, it will pick it up automatically.
b
well - it didn't. it overwrote the already existing Pulumi.yaml, even when i did not have any
projectSettings
defined.
l
If you specified
workDir
without explicit
projectSettings
then this behavior would be a bug and we should fix it. If you have a repro, please share or file an issue: https://github.com/pulumi/pulumi/issues/new?assignees=&amp;labels=kind%2Fbug&amp;template=0-bug-report.md
b
Bug raised: https://github.com/pulumi/pulumi/issues/6632 Includes link to repo for reproduction.