-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Assume web is the default for older buildpacks #204
Assume web is the default for older buildpacks #204
Conversation
Signed-off-by: Natalie Arellano <narellano@vmware.com>
8f57679
to
ff640ab
Compare
@yaelharel I took a stab at it - do you mind taking a look at it? Note that these are only the platform changes... |
Signed-off-by: Natalie Arellano <narellano@vmware.com>
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.
Looks good to me! @dwillist, would you mind reviewing it as well?
@@ -893,6 +899,8 @@ Where: | |||
|
|||
#### `metadata.toml` (TOML) | |||
```toml | |||
buildpack-default-process-type = "<process type>" |
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.
Do we need the "buildpack-" prefix here? Should we add a top-level key?
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 wanted buildpack-
to differentiate between the buildpack-provided default and user-provided default (via the -process-type
flag). We thought it would be confusing if the app had default process type some-user-type
and metadata.toml contained default-process-type = some-buildpack-type
. An alternative that we considered was deleting this key from metadata.toml prior to export, so that it is only used to pass information between phases.
As for whether it should be a top-level key, I'm not sure... we thought about adding default = <true or false>
under each buildpack but then we also thought it would be confusing given that multiple buildpacks can each contribute a default and it wouldn't be obvious to the reader of this file that "last wins".
cc @yaelharel please add if I missed anything!
Fixes #160
Signed-off-by: Natalie Arellano narellano@vmware.com