pre/post compile hooks about dockerbuilder HOT 9 OPEN

From @mboersma on September 13, 2016 21:17

This general idea works well for buildpack-based apps (now that deis/slugbuilder#104 landed).

It would be useful to have a similar pre-/post-compile hook mechanism for Dockerfile apps, as well as for deis pull deploys. We should put some thought into how to implement that in a consistent way--suggestions welcome!

from dockerbuilder.

From @robholland on October 14, 2016 13:6

This probably belongs on deis/controller then?

from dockerbuilder.

From @pixeleet on October 14, 2016 13:55

So controller would setup the service you depend on for testing? Would it work with shell scripts? Would it be a DSL like some ci systems use? How do you imagine it working @robholland?

from dockerbuilder.

From @bacongobbler on October 14, 2016 15:20

I still think it's fair to keep it here for the time being until someone writes out a design document/PR for the proposed feature.

from dockerbuilder.

From @robholland on October 14, 2016 20:56

Simplest functionality would be to specify commands that are run inside the container after build/pull. This would be useful for asset compilation for example, which needs to be run with the correct environment.

from dockerbuilder.

From @robholland on October 18, 2016 16:23

How about:

$ deis hooks:post:list
=== app Post Hooks
$ deis hooks:post:add 'bundle exec rake assets:precompile'
=== app Post Hooks
bundle exec rake assets:precompile
$ deis hooks:post:remove 'bundle exec rake assets:precompile'
=== app Post Hooks

The registered commands are run inside the docker container after build and before deployment to k8s.

from dockerbuilder.

From @bacongobbler on October 18, 2016 16:44

I'm concerned about the added time to run the one-off command in the same API call as when we build the app. We're already seeing a large number of issues come in that's usually ELB-related with the builder timing out.

If you're willing to take a crack at a PR as well as some end-to-end tests, I don't see an issue with the proposal as long as it works.

from dockerbuilder.

From @bacongobbler on March 22, 2017 21:5

Does anyone have the time to work on this or shall we remove from the milestone since the cut-off for v2.13 is April 3rd?

from dockerbuilder.

From @mboersma on March 22, 2017 21:15

It seems unlikely we can tackle this in time for v2.13. I'll kick it into the future.

from dockerbuilder.