https://pulumi.com logo
Powered by
d

dry-pilot-49577

08/31/2023, 10:40 PM
This is one of those "I don't know what to ask to ask a good question" questions. I've got a 
local.Command
that feeds into another 
local.Command
. The first command works, and I can even see the 
stdout
being saved correctly. The second item is created as
Copy code
const cloud = service.stdout.apply(p => JSON.parse(p));
const app = new local.Command(
  `${ns}-app`,
  {
    create: "./create.sh",
    delete: "./delete.sh",
    environment: pulumi.all([cloud.appId]).apply([appId] => ({TEST: "yes", APP_ID: appId})),
  },
 );
I dumped the env to a log file and 
TEST
is there, but 
APP_ID
isn't. 
service.stdout
exists and is set correctly according to 
pulumi stack export > p.json
1. Does 
local.Command
not check for dependencies before firing off its shell command? 2. If it does, is there some other syntax to ensure 
${ns}-app
waits for 
service.stdout
to resolve correctly?
l

little-cartoon-10569

08/31/2023, 11:05 PM
It does. Is the command already created? If the Command resource has been created, and appId hasn't changed, then a new Command won't be created. This is expected.
BTW, 
pulumi.all([x]).apply([x] => ...)
is exactly the same as 
x.apply()
. Also, 
pulumi.interpolate
is sugar around 
x.apply()
, when you're only generating a string.
d

dry-pilot-49577

08/31/2023, 11:09 PM
The command (from service.stdout) is created, and it has the 
.appId
property in the stdout JSON It just... never makes it into the environment of the second command which has truly perplexed me. I originally had environment as 
{ APP_ID: cloud.appId }
but that also wasn't working.
I'll see if I can pull out a gist minus anything sensitive
https://gist.github.com/jakobo/b3203b832c28f6cac8c28225615752f7 We're moving some realm configuration into pulumi. We can't use a dynamic resource b/c mongo loves to make things undefined (and as a result you step on a lot of 
Error: Undefined struct type
) 01 - this file is the application (the cloud from previous). In its stdout from 
local.Command
is the property we pass onward (appId) 02 - an example of a downstream dependency on the app object. It's here where 
MONGO_APP_ID
comes up undefined, causing 
fromEnv()
to fail safely and avoid writing undefined values into the state 03 - The glue, a Component Resource, showing the stitching from the app object to the others
(appreciate the extra eyes. Usually by this point I assume it's b/c I've done something truly dumb)
Source of issue: Bad JSON deserialization. 😭
l

little-cartoon-10569

08/31/2023, 11:47 PM
Dang, I had just opened the gist to look at it 🙂 Well done on finding the issue!
d

dry-pilot-49577

08/31/2023, 11:48 PM
TypeScript and JSON.parse are going on my list of typescript landmines 😞
l

little-cartoon-10569

08/31/2023, 11:48 PM
Haven't yet needed to use JSON.parse in a Pulumi project. Somehow, every time I've used it, I've realized that there was a simpler alternative for that bit of code. Often, just casting works.
d

dry-pilot-49577

08/31/2023, 11:52 PM
That was my flaw. I cast to my api response, forgetting I wrapped it in a parent object so that I could capture environment values for local.Command on delete
l

little-cartoon-10569

08/31/2023, 11:54 PM
Ah. The power of intellisense can be misused, and ruin your day!
d

dry-pilot-49577

08/31/2023, 11:57 PM
I appreciate the rubber ducking. My only regret was not asking at the start of the afternoon. 🙂
Powered by