Project for Dockerfiles proof of concept#113
Conversation
Signed-off-by: Natalie Arellano <narellano@vmware.com>
Signed-off-by: Natalie Arellano <narellano@vmware.com>
| [[buildpacks]] | ||
| id = "samples/curl" | ||
| version = "0.0.1" | ||
| uri = "../../extensions/curl" |
There was a problem hiding this comment.
If the extensions uri is part of the [[buildpacks]] block, how the builder tool will be able to package within the image, the buildpacks containing the bin/detect, bin/build vs extensions as the existing uri parameter is used to fetch buildpacks content only ?
Why don't we package the extensions part of a separate block [[extensions]].
Why such a proposition:
- To be able to resolve the problem reported in my previous remark when the builder tool is creating an image,
- To allow to add new extensions when new builder images are created independently of the existing buildpacks
- To make the extension independent of the buildpacks*
*: If the buildpack detects that a tool, package is needed (curl, maven, java, ...), then it can report (maven 3.x is needed), then the extension phase-step could then be called to install the corresponding tool/command (e.g curl, java, maven, ... ) for the suggested version before the build phase is called.
REMARK: That implies that an extension is designed as a kind of module to install according to the name of the extension, what the name refers instead of zillions of packages
There was a problem hiding this comment.
Strongly agree -- let's add a separate [[extensions]] table.
Also, can we do the same with [[order]] and create a separate [[order-ext]] table?
There was a problem hiding this comment.
Also, can we do the same with
[[order]]and create a separate[[order-ext]]table?
I think that we need such an order table but how will it be possible to it them easily as ideally the extensions should be independent.
Will the builder be able to understand that java should be installed before maven, that curl should be the first ....
Instead of defining a specific order I would prefer to delegate to the detect phase of the buikldpack the responsibility to report to the extension phase (= optional step taking place before the build phase if extensions exist) what it is needed and required.
There was a problem hiding this comment.
That is an interesting question about the order. My understanding is from the RFC is that extensions should always come first in the order. The separate [[order-ext]] table is a bit confusing to me, as what would happen if multiple groups are defined there? This would change the lifecycle implementation (detect would happen separately for extensions vs. buildpacks).
Signed-off-by: Natalie Arellano <narellano@vmware.com>
Signed-off-by: Natalie Arellano <narellano@vmware.com>
6face50 to
64ac5d3
Compare
Signed-off-by: Natalie Arellano <narellano@vmware.com>
Signed-off-by: Natalie Arellano <narellano@vmware.com>
|
This can be closed, the test data was moved into buildpacks/lifecycle#802. |
No description provided.