main does not set working dir correctly for Lambda zip?
#667
Comments
|
This is blocking being able to add tests for the PPC infrastructure, which I believe is critical to add in 0.9.1. Pulling this into the milestone as well, to either fix or identify a workaround. Note that we could also "fix" this by getting |
|
Indeed - we only pass the |
|
IMHO we should probably require the langhost to pass an absolute path for all assets, rather than introducing a requirement that the processes share a working directory. /cc @pgavlin |
|
Perhaps - though we do not want to serialize an absolute path into the checkpoint file. |
|
@lukehoban Did you plan to take a look at this? The bug is currently unassigned and I wasn't sure if you were asking either @pgavlin or I to take it from here. |
@lukehoban is correct; we definitely do not want to be serializing absolute paths into checkpoints. I think that it would be reasonable to require that all paths from the language host are either a) absolute, or b) relative to the directory that contains |
|
That sounds like a nice solution. |
This change just flows the project's "main" directory all the way through to the plugins, fixing #667. In that work item, we discussed alternative approaches, such as rewriting the asset paths, but this is tricky because it's very tough to do without those absolute paths somehow ending up in the checkpoint files. Just launching the processes with the right pwd is far easier and safer, and it turns out that, conveniently, we set up the plugin context in exactly the same place that we read the project information.
This change just flows the project's "main" directory all the way through to the plugins, fixing #667. In that work item, we discussed alternative approaches, such as rewriting the asset paths, but this is tricky because it's very tough to do without those absolute paths somehow ending up in the checkpoint files. Just launching the processes with the right pwd is far easier and safer, and it turns out that, conveniently, we set up the plugin context in exactly the same place that we read the project information.
This change just flows the project's "main" directory all the way through to the plugins, fixing #667. In that work item, we discussed alternative approaches, such as rewriting the asset paths, but this is tricky because it's very tough to do without those absolute paths somehow ending up in the checkpoint files. Just launching the processes with the right pwd is far easier and safer, and it turns out that, conveniently, we set up the plugin context in exactly the same place that we read the project information.
This change just flows the project's "main" directory all the way through to the plugins, fixing #667. In that work item, we discussed alternative approaches, such as rewriting the asset paths, but this is tricky because it's very tough to do without those absolute paths somehow ending up in the checkpoint files. Just launching the processes with the right pwd is far easier and safer, and it turns out that, conveniently, we set up the plugin context in exactly the same place that we read the project information.
This change just flows the project's "main" directory all the way through to the plugins, fixing #667. In that work item, we discussed alternative approaches, such as rewriting the asset paths, but this is tricky because it's very tough to do without those absolute paths somehow ending up in the checkpoint files. Just launching the processes with the right pwd is far easier and safer, and it turns out that, conveniently, we set up the plugin context in exactly the same place that we read the project information.
This change just flows the project's "main" directory all the way through to the plugins, fixing #667. In that work item, we discussed alternative approaches, such as rewriting the asset paths, but this is tricky because it's very tough to do without those absolute paths somehow ending up in the checkpoint files. Just launching the processes with the right pwd is far easier and safer, and it turns out that, conveniently, we set up the plugin context in exactly the same place that we read the project information.
|
Fixed in b6a3869. |
It appears that references to
.in assets used for Lambdas will use the actual working directory, not the folder thatmainpoints to.I believe the contract for
mainis that it sets the working directory for execution of the program. If so, it should use this for interpretation of.in Assets as well.This leads to Lambda zip files being too large when used in setups with a Pulumi.yaml in a root folder.
See for example the failures in https://travis-ci.com/pulumi/pulumi-ppc/builds/61152492, based on layout in https://github.com/pulumi/pulumi-ppc/tree/464c475794ee36f5c80f744d70bd816731448a3c/infrastructure.
The text was updated successfully, but these errors were encountered: