-
Notifications
You must be signed in to change notification settings - Fork 799
Expose runtime configuration during slugbuilder execution #960
Conversation
Gonna need to be careful with 9a2312a, but otherwise looks great! @gabrtv could you please add docs for this PR at http://docs.deis.io/en/latest/developer/? It could fall under http://docs.deis.io/en/latest/developer/deploy-application/, but I think it needs its own page much like https://devcenter.heroku.com/articles/config-vars. https://github.com/bacongobbler/heroku-buildpack-jekyll might be a better example with this PR as it should work out of the box. |
@bacongobbler I am going to address documentation holistically in the next PR, which will be the improved Dockerfile handling -- coming soon to a theater near you. |
user = get_object_or_404( | ||
User, username=request.DATA['receive_user']) | ||
# check the user is authorized for this app | ||
if user == app.owner or user in get_users_with_perms(app): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't we be utilizing a permissions class for this logic instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are actually using a permissions class specified in the parent (HasBuilderAuth
). The more granular check (user is authorized for this app) could be ported to a PermissionsClass, but it's a bit more work and would require refactoring the other hook views. Again I'm open to it, just not in this PR.
Added back |
What is the best way to test this? Is setting a custom buildpack URL as you did adequate, @gabrtv? |
Still need to test, but LGTM from my point of view :) |
@carmstrong yes, custom buildpack URL is the easiest test. |
@gabrtv Could you please rebase off master so we have the /etc/hosts fix for the Docker CDN? |
This uses a new Config API Hook to grab the latest app configuration and expose it to slugbuilder using `-e` flags. While this works, it is a very good mechanism for handling user-defined inputs on the builder. In other words, command-injection is possible through malformed inputs. We must consider this as we move to refactor the builder in Go.
As part of the effort to move code from views into models, we would always scale an app to an initial structure on every deploy. This made it impossible to, for example, set a BUILDPACK_URL without triggering a false deploy and timeout. Moving the logic back into the BuildView where it belongs.
@carmstrong done. |
Finally completed testing this. LGTM - works as advertised. |
Works as advertised for me as well:
hehehe... LGTM! |
Nice test. Single quotes ftw. |
Expose runtime configuration during slugbuilder execution
Fixes #462.
This PR uses a new Config hook to grab the latest app configuration from the controller and expose it to slugbuilder using
-e
flags. While this works, it is not a very good mechanism for handling user-defined inputs on the builder. We must consider this as we move to refactor the builder in Go.Example of setting a custom BUILDPACK_URL:
Note this particular buildpack doesn't contain a
bin/release
and errors with:.. but that's not our problem.