https://pulumi.com
Join Slack
This message was deleted.
# typescript
s
This message was deleted.
Source.ts
l
generateTmpFile()
is called in 
apply()
, which is a future. 
CopyFile
is constructed now, before 
generateTmpFile()
runs. The file doesn't exist at this time.
BTW most of that code isn't related to the problem; shorter posts are easier to read and help others find the problem faster.
i
So what would be a proper way of doing this?
l
You could copy the file inside the apply. You probably wouldn't use pulumi.command for that though. Or you could use another Pulumi resource (maybe a pulumi.local.Command) to create the temp file, so that the CopyFile can depend on it. That way Pulumi can manage the order of events.
Strictly speaking, you could chain another apply onto the file-generating one, but you shouldn't create a resource in there. So CopyFile shouldn't go in there.
i
How would I clean up the temp file created by local.Command, just another Command removing the file after it has been copied?
Or well could also run remote.command that creates the file
l
You could rely on the system to do it (which generally happens each time there's a reboot). Or you could create the temp file using tmp outside the apply, so that it is created in advance, and just pass a reference to it to where it's needed.
The apply is guaranteed to run after the non-applied code (I think). It's safe to rely on that (I always do and have never been caught out.)
i
How could I create the tmp outside the apply when I need a value from the config for the content of the tmp? Sorry just trying to understand everything.
l
You can create the file before writing to it.
i
And then I write to it through the command resource?
And make the container depend on command resource?
l
That's an option, sounds good. There may be all sorts of other solutions, of course 🙂
I've just noticed that the value you're creating the content from is a configuration value.
It's not from another resource.
i
Does that change things? 😅
l
Well, it should, since it's technically available before the program starts. But 
requireSecret()
returns an Output, because that's where the info about being a secret is kept.
Does CopyFile (which I've never used) accept an Output as the source? If it does, you could create the file in there.
i
It sucks it can't accept a content input or some thing like that..
l
Grr, that silly idea that they hide the Input/Output of constructor parameters in the docs.
I'll look in the actual code 🙂
❤️ 1
Yep, it's an Input<string>. So you could do the work there.
Onesec I'll hack your code above.
i
Thanks was about to ask 😅
l
Hmm. It's already suitable. That apply should resolve before the copy does. There must be a bug in the library.
Or else my analysis is off, which is likely too. I shall look in the code for CopyFile.
i
You sir are a soldier 🫡
l
My golang isn't the best, but it looks like reading the file is correctly done in the engine: https://github.com/pulumi/pulumi-command/blob/9858a482d99e7331dd5962602fd3010637647e79/provider/pkg/provider/remote/copyfileController.go#L65 I was "hoping" that it was a bug like in the old Docker provider, where reading was done in the resource constructor.
If this is correct and the file is read after its inputs resolve, then your code should work.
i
In an event that it doesn't (it doesn't), how would I go about troubleshooting?
l
The best reason I can think that it doesn't wait would be maybe 
cfCredsTmpFile.name
doesn't wait for the rest of the outputs: maybe there's some other way to rework that line so that you know the apply() has completed?
Is 
name
a special property? This is an output from a RequireSecret, let's have a look at that code.
i
.name is a parameter of the return object of generateTmpFile function
l
It's tmpFile.name, yep. So there's no reason why the tmpfile wouldn't have been created at that time.
It is possible that /pulumi/cf-credentials/ doesn't exist? The error message doesn't say which file doesn't exist... maybe I was wrong in my assumption that it was localFile?
i
The directory?
l
Yes. That machine is created from a vanilla image, I can't see anything in there that creates that directory, are you sure it's already there in the container?
i
I thought copyfile will create directories automatically?
We're talking about line 60 right?
l
I don't see anything in the docs suggesting that.
yes
i
let me try running mkdir before
l
mkdir --parents
🙂
❤️ 1
i
Well it was exactly that
l
Good stuff.
Pity that error message is so vague. Could have saved ourselves 30 minutes :)
i
Sucks a bit we need to run a command mkdir before copyfile, I'd assume copyfile handles non existent parent directories.
l
No, I think that's by design. All copy commands in all OSes do exactly that.
There needs to be a way to fail to copy if the directory doesn't exist and you don't want it to exist.
For example, if the dest parameter is wrong, or if you only want it to work if things are configured in a particular way.
i
Fair
Thank you so much for your immense help.
Saved me probably a couple hours.
l
It wasn't that immense, I just made it bigger through assumptions. 30+ years in the industry, you'd think I'd assume fewer things...
i
Haha, don't we all assume everything, I assumed a directory will be created automatically (spoiled like that)
l
👍 Anyway, season's greetings🎄and good luck with the rest!
i
Cheers!
21 Views
Open in Slack
PreviousNext
Powered by

Pulumi Community

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.

Powered by