It appears that if an absolute path is passed to

FileArchive

then pulumi will have a hard time on another machine and will fail to update 😬 Is this expected? If so might be worth adding a warning or explicit mention of relative path requirement on the docs. I do wonder how we should handle non-deterministic paths though between builds? I have a "file not found" error where a

BucketObject

is referencing a

.zip

with an absolute path which was created running

up

on another machine.

That sounds like a normal programming issue. Exception handling and testing are the way to go, here.

Yes.

There isn't a relative path requirement, so it can't be added to the docs. The relative path thing is a requirement only when running on multiple machines with different directory hierarchies. Frequently, this isn't the case.

It's not my code throwing the exception though. Pulumi is storing in state (validated via

pulumi stack export

) an absolute path that is not valid across environments.

So the exception handling would have to wrap the execution of the Pulumi engine, which is inconvenient but not difficult.

Err, not really agreeing with your sentiment. Of course we should "handle errors that could occur in your code". However, I believe this error should be handled by pulumi. In my configuration it is correctly pointing to the right file path that exists on the machine pulumi is running on. Pulumi is trying to do something with the old state and failing - which I'm pretty sure is the biggest jobs of pulumi (ie. to detect configuration drift so that it can perform the right CRUD actions). It's seeing "oh this FileArchive doesn't exist anymore" but I've got a new one in it's place and do not have control over what pulumi is doing in the background when it realises an old FileArchive resource is orphaned.

If Pulumi did that, how would you handle the case where you require the file to be at a specific, absolute location? And where if it path changes, then deployment should correctly fail?

The problem is apparent when you consider the

Asset

resources are the only resources that do not have a stable name you can provide. It is expecting to use the file path as a stable reference for the "virtual resource" AND as a pointer to "physical resource".

That does complicate matters...

Yeah defo will do. Thanks for helping me validate the issue

I think I understand your problem now. You had old state that refered to one file, and now you've moved to a new machine and that file doesn't exist anymore and you've changed your program to use a new file path. But when pulumi runs it's still trying to actually read the file at the old path and causing a file not found error? Could you ping us the output from up so we could see where exactly this error is showing up, a quick look at the engine code suggests we should be handling the case of the old file going missing without issue.

That's the one. The more I'm thinking about it the more likely it might be tied in with my other linked issue related to

source: FileArchive

and

sourceHash

I don't think its needed but we'll ping on the ticket if that changes.