Alternate fork to use? about buildstep

[stuartpb]

My opinion is that a straight fork of buildstep would be a mistake - implementing the build process / buildpacks as part of the container is fundamentally flawed.

The plan for Plusku (plushu/plushu-buildstep#5) is to develop an alternative build plugin (plushu/plushu-build-cedarish) that will use the progrium/cedarish image, a modified version of progrium/buildstep's stack/builder script (merged with builder/build.sh from Flynn's slugbuilder), and whatever buildpacks the user has installed (mounted as a volume).

For now, Plusku is still using plushu-buildstep - the transition to plushu-build-cedarish will happen after Git retrieval is abstracted out of plushu-plugins-plugin. (There will also be a plushu-buildpacks plugin, for managing installed buildpacks, and plushu-plusku-buildpacks and plushu-buildstep-buildpacks meta-plugins for installing sets of buildpacks (buildstep-buildpacks will be the exact same list of buildpacks as progrium/buildstep; plusku-buildpacks will be a modified list that takes things like the standing PRs for buildstep into consideration).

[mjonuschat]

I'm not trying to reinvent the wheel and rebuild everything. I'm dogfooding my own stuff on a couple of machines and I'm really happy with it. The image I have published on docker includes a few more fixes and features than PR #109, especially since I needed multiple processes and a generic fix for the PHP problem. I'm trying to stay compatible with dokku and dokku-alt and currently the image does that. On dokku a single process gets started on deploy, ln dokku-alt one of each defined in the Procfile. In the near future I want to get theses fixes into the default buildstep since I think that is the best solution and avoids fragmentation...

[progrium]

I'm starting sponsored work on buildstep/Dokku next week.

On Thu, Oct 9, 2014 at 5:19 PM, Morton Jonuschat [email protected]
wrote:

I'm not trying to reinvent the wheel and rebuild everything. I'm
dogfooding my own stuff on a couple of machines and I'm really happy with
it. The image I have published on docker includes a few more fixes and
features than PR #109 #109,
especially since I needed multiple processes and a generic fix for the PHP
problem. I'm trying to stay compatible with dokku and dokku-alt and
currently the image does that. On dokku a single process gets started on
deploy, ln dokku-alt one of each defined in the Procfile. In the near
future I want to get theses fixes into the default buildstep since I think
that is the best solution and avoids fragmentation...

—
Reply to this email directly or view it on GitHub
#111 (comment).

Jeff Lindsay
http://progrium.com

[kenips]

@progrium thank you thank you thank you thank you! And to whoever made this happen. And hopefully soon we don't have dokku / dokku-alt split.

[arthurnn]

❤️ ❤️ ❤️ ❤️ @progrium

[stuartpb]

Update on Plusku's implementation: I've done the work for buildpack management (plushu-buildpacks and plushu-buildstep-buildpacks are both implemented), and am now working on the actual plushu-build-cedarish plugin using https://github.com/yabawock/buildstep/blob/feature/modernize/builder/builder as a starting point (thank you @yabawock).

[mjonuschat]

@stuartpb You might want to take a look at the feature/run-as-user branch as well, it fixes the permission problems with newer PHP versions (5.4.28+, 5.5.12+, 5.6.0+) and the bundler warning in rails

[stuartpb]

@yabawock Yeah, I'm looking at it: plushu/plushu-build-cedarish#1

Right now I have a fever that's making it kind of hard to concentrate on jumping between half-a-dozen issue comment threads and pull request diffs while architecting a separate set of build scripts, so I'm probably going to take a break for the rest of the night.

Also, right now a key component of the public sandbox I've set up for testing Plushu is an app that actually depends on being run as root (http://enter.sandbox.plushu.org), so I'm going to have to either redesign that aspect of the app, or build an option to let apps build and/or run as root into the build script(s) (I'm leaning toward the latter).

[progrium]

I'm trying to clean up, so I'm going to close this since a number of alternatives have been mentioned.