pre/post compile hooks

[pixeleet]

As a Developer using the Deis platfrom I'd like to have pre/post compile hooks available for dockerfile based builds too, so I can execute checks that my services required for tests are alive and execute tests after an image has been made. Thus making my flow more CI/CD enabled.

[mboersma]

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!

[robholland]

This probably belongs on deis/controller then?

[pixeleet]

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?

[bacongobbler]

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.

[robholland]

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.

[robholland]

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.

[bacongobbler]

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.

[bacongobbler]

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?

[mboersma]

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