search

nimbella / nimbella-cli

Your cloud. Beautiful.
https://nimbella.com
Apache License 2.0
10 stars 12 forks source link

The "self-contained" restriction on remote builds is documented obscurely and results in an obscure error. #91

Open rabbah opened 3 years ago

rabbah commented 3 years ago

Ran this from the workbench:

> nim project deploy github:nimbella/demo-projects/hello-typescript#ts --remote-build

The reason I'm using a ts branch is because I didn't commit a project.yml to master but it's required for the remote build.

The error reported is:

Deploying project 'github:nimbella/demo-projects/hello-typescript#ts'
  to namespace '...'
  on host '...'
Submitted action 'hello' for remote building and deployment in runtime nodejs:default
Transcript of remote build session for hello:
Started running ./build.sh in nimbella/demo-projects/hello-typescript/hello-ts/hello
Output of failed build in /tmp/slices/2021-04-09T03-03-22.535Z/packages/hello-ts/hello
./build.sh: line 7: ../../../lib/build.sh: No such file or directory

Failures:
Error: While deploying action 'hello-ts/hello

The same build of course works locally.

nim project deploy github:nimbella/demo-projects/hello-typescript#ts
Deploying project 'github:nimbella/demo-projects/hello-typescript#ts'
  to namespace '...'
  on host '...'
Started running ./build.sh in nimbella/demo-projects/hello-typescript/hello-ts/hello
Still running ./build.sh in nimbella/demo-projects/hello-typescript/hello-ts/hello
Finished running ./build.sh in nimbella/demo-projects/hello-typescript/hello-ts/hello

Deployed actions ('nim action get <actionName> --url' for URL):
  - hello-ts/hello
joshuaauerbachwatson commented 3 years ago

In https://docs.nimbella.com/actions#using-an-action-source-file-from-elsewhere-in-the-project, it is documented (I think pretty obscurely, true) that

If you wish your build to execute remotely as described in Remote Builds, 
you may not include material from outside the directory.

I have been aware that this restriction is counter-intuitive, because, in all other cases we deprecate (but do not forbid) including things from outside the project and encourage including things from inside the project that are outside the directory being deployed.

I believe this special restriction can be lifted (carefully and maybe a bit painfully) by changing how the project slice is calculated for remote building. The tricky thing is not to unconditionally send the whole project to each runtime since that could potentially incur a lot of overhead.

I think one short-term action item is to replay this verbiage in the section on remote builds, since it is an important restriction that is easy to miss.

A second short-term action item might be to try to detect this condition as part of the slice calculation and abort if detected. This would be a prelude to the "righteous fix" sketched above.

joshuaauerbachwatson commented 3 years ago

I've changed the title consistent with the "real problem" as narrowly defined. @rabbah you could also change this to an enhancement, in which case the title would be about relaxing the restriction.

rabbah commented 3 years ago

outside the directory being outside a packages/pacakge-name/action-name directory? (the build script is in the project but the project is organized with packages and lib folders at the same level, the build.sh in the action-name directory delegates to a build in lib.

joshuaauerbachwatson commented 3 years ago

outside the directory being outside a packages/pacakge-name/action-name directory?

Yes. That's what it means.

(the build script is in the project but the project is organized with packages and lib folders at the same level, the build.sh in the action-name directory delegates to a build in lib.

I know it's in the project. That does not currently help in the case of remote build.

joshuaauerbachwatson commented 3 years ago

I am tripping over this issue now in a project that has a lot of actions that need to be built remotely. I can work around it (as anyone can) by adding a driving script for the project deployment that starts by copying common material into the individual actions. Not very nice. I think I can see a solution that might be easier than I feared. @rabbah if you want to take me up on that you can assign this to me.