Conversation
Signed-off-by: Javier Romero <rjavier@vmware.com>
|
Maintainers, As you review this RFC please queue up issues to be created using the following commands: Issues(none) |
Signed-off-by: Javier Romero <rjavier@vmware.com>
|
|
||
| > If multiple files exist, `toml` would be selected. | ||
|
|
||
| #### TOML |
There was a problem hiding this comment.
For a dot-file, i would expect this file structure to map directly to the pack commands. So a table for each command, with
[build]
builder = ""
clear-cache = true
[[build.buildpacks]]
id = "and so on...
There was a problem hiding this comment.
I thought about the build table but given that all of the properties only apply to build I didn't see the need to add a layer of depth that the users need to repeatedly add.
Signed-off-by: Javier Romero <rjavier@vmware.com>
|
|
||
| To prevent unnecessary complexity for end-users (app developers), the `buildpacks.<ext>` file would only support properties associated with Cloud Native Buildpacks. See full list of properties in the [file](#file) section. | ||
|
|
||
| ### Cross-Platform Support |
There was a problem hiding this comment.
This doesn't appear to improve on the status quo (project.toml). The buildpacks.* would. need to be converted into another format to become cross-platform supportable.
There was a problem hiding this comment.
It does in that Platforms become required to support buildpacks.*. That said, we could do the same to project.toml. This RFC tries to paint a new picture on a CNB specific config file that becomes required for platforms to support.
There was a problem hiding this comment.
what are the advantages of requiring this file over project.toml?
|
|
||
| ## File | ||
|
|
||
| `buildpacks.<ext>` where `<ext>` corrolates to a supported format. |
There was a problem hiding this comment.
this is way too easily confused with buildpack.toml
There was a problem hiding this comment.
I agree but do we expect app developers to be using buildpack.toml? To me, they are separated enough in context that I personally don't get troubled.
Alternatively, maybe something like Buildpacks, with no extension, similar to Dockerfile.
There was a problem hiding this comment.
I agree but do we expect app developers to be using buildpack.toml?
If we don't, I think that makes the problem worse, because they won't even notice when they need to pay attention to the differences.
|
|
||
| #### TOML | ||
|
|
||
| ```toml |
There was a problem hiding this comment.
this doesn't look any less complex to me than project.toml
| # Drawbacks | ||
| [drawbacks]: #drawbacks | ||
|
|
||
| Why should we *not* do this? |
There was a problem hiding this comment.
buildpacks.*is easily confused withbuildpack.tomlbuildpacks*is not inherently portable. We still need to implement a mechanism and more spec to convert it to something portable- yet-another-config-file: I won't have a place to put config that's common across tools (license, include/exclude, version, image names, etc)
- doesn't map well to pack commands/flags
|
You should keep in mind that #187 (when merged) would cause a small change in the proposed file content. |
|
Should we close this? |
5 participants
An alternative to project descriptor that is solely focused on Cloud Native Buildpacks.
Rendered