Implementing

[stuartpb]

continued from plushu/plushu-buildstep#5

[stuartpb]

Here's my plan:

Write a build process using ideas from progrium/buildstep#109, especially the unincluded patches mentioned in progrium/buildstep#109 (comment), specifically yabawock/buildstep@4c84186. Compilation will be a script, and it will be called by a wrapping script that creates a temporary non-privileged user to do the build (and, later, to do the run as well).

Might also take another look at progrium/buildstep#98, integrate some of that.

Also, since it's possible that an app may want to run as root (as discussed in plushu/enter-sandbox#5), maybe some mechanism to skip the user drop (using a mechanism like the one to keep the git directory in plushu-git-apps) should be included.

Scripts for building are going to be included in this plugin's lib/ directory, which will be mounted in the image as a volume at /build (similar to the build directory in buildstep). The build-app-commands stuff will work the same as plushu-buildstep, with a self-hook that runs the entry script in /build.

[stuartpb]

Because of the let's-not-break-enter-sandbox-right-now fuss of plushu/enter-sandbox#5, I think I'll actually table the user-creation stuff for now and just start with a straight build-and-run-as-root build script, maybe factoring it to be a little closer to the structure that will be needed to create such a framing user.

Then I'll tackle the framing user stuff later, with another issue for the architectural concerns and decisions involved, including the relevant stuff for possibly allowing root build/runs.

[stuartpb]

Differences from buildstep

(based on yabawock's script)

• We don't source .env files in the app before compiling (Flynn's slugbuilder doesn't either). This might have been a user-env-compile thing, but Heroku never actually used user-env-compile outside of experiments (they settled on ENV_DIR for exposing the config to scripts).
  • We do source the app's build.rc, for build-time configuration.
• We don't handle retrieving custom buildpacks. If the user wants a custom buildpack, they can just install it.
  • We do allow setting a specific path for your buildpack if you want to select a specific installed buildpack.
  • This buildpack retrieval could be added with a plugin, if you really need this kind of compatibility, but in general it's not well orthogonal to Plushu / Plusku.

[stuartpb]

Seeing as how this is implemented now (except for the non-root stuff), I'm going to close this issue and open another one for the root thing.