Application Mixins (only) #112
Conversation
Signed-off-by: Joe Kutner <jpkutner@gmail.com>
jkutner
force-pushed
the
app-mixins-only
branch
from
0b26fd4
to
3342819
Compare
| 1. If all mixin names are provided by the stack, no further action is required. | ||
| 1. If any requested mixin is not provided by the stack, the lifecycle will run the detect phase for all stackpacks defined in the builder. | ||
| 1. The lifecycle will compare the mixins added to the build plan to see if they match they required mixins. | ||
| 1. If at least one stackpack passes detect and provides the required mixin(s), the lifecycle will execute the stackpack build phase for all passing stackpack(s). If no stackpacks pass detect, or no stackpacks provide the required mixin, the build will fail with a message that describes the mixins that could not be provided. |
There was a problem hiding this comment.
It's not clear to me how detect opt-in and buildplan interact. I'm guessing that stackpack_a opts in and provides mixin_a/mixin_b.
But what if stackpack_b opts in and provides mixin_b? Will it also be used, or skipped?
What if a stackpack provides more than what the user wants?
| 1. If any requested mixin is not provided by the stack, the lifecycle will run the detect phase for all stackpacks defined in the builder. | ||
| 1. The lifecycle will compare the mixins added to the build plan to see if they match they required mixins. | ||
| 1. If at least one stackpack passes detect and provides the required mixin(s), the lifecycle will execute the stackpack build phase for all passing stackpack(s). If no stackpacks pass detect, or no stackpacks provide the required mixin, the build will fail with a message that describes the mixins that could not be provided. | ||
| 1. During the lifecycle's build phase, the stackpacks that passed detection will run against the build and run images accordingly (see details below). All stackpacks will be run before the user's buildpacks. |
There was a problem hiding this comment.
I guess this answers it. So everyone that opts-in will be run, regardless of if they overlap, or provide more mixins than the user needs.
There was a problem hiding this comment.
I suggest that we resolve this more cleanly. Maybe we could implement a push-forward mechanism, like we have with build plan entries?
If we implemented the protocol for this entirely on top of the build plan mechanism (perhaps with a mixin = true option in each entry), it might reduce some of this complexity.
| 1. If any requested mixin is not provided by the stack, the lifecycle will run the detect phase for all stackpacks defined in the builder. | ||
| 1. The lifecycle will compare the mixins added to the build plan to see if they match they required mixins. | ||
| 1. If at least one stackpack passes detect and provides the required mixin(s), the lifecycle will execute the stackpack build phase for all passing stackpack(s). If no stackpacks pass detect, or no stackpacks provide the required mixin, the build will fail with a message that describes the mixins that could not be provided. | ||
| 1. During the lifecycle's build phase, the stackpacks that passed detection will run against the build and run images accordingly (see details below). All stackpacks will be run before the user's buildpacks. |
There was a problem hiding this comment.
I suggest that we resolve this more cleanly. Maybe we could implement a push-forward mechanism, like we have with build plan entries?
If we implemented the protocol for this entirely on top of the build plan mechanism (perhaps with a mixin = true option in each entry), it might reduce some of this complexity.
|
|
||
| ## Rebasing an App | ||
|
|
||
| Before a launch image is rebased, the platform must re-run the any stackpacks that were used to build the launch image against the new run-image. Then, the rebase operation can be performed as normal, while including the stackpack layers as part of the stack. This will be made possible by including the stackpack in the run-image, but because the stackpack detect phase is not run, the operation does not need access to the application source. |
There was a problem hiding this comment.
How would the list of mixins used be persisted from pack build to pack rebase? I believe that paketobuildpacks make sure that the application code (if it can be compiled into a binary) isn't on the final image - does this require that the project.toml file be kept? Or will the list of used mixins/stackpacks be persisted through another mechanism?
There was a problem hiding this comment.
This is addressed in RFC-0069: Stack buildpacks. They will be stored in a LABEL.
| - [Add root buildpack as interface for app image extension RFC](https://github.com/buildpacks/rfcs/pull/77) | ||
| - [App Image Extensions (OS packages)](https://github.com/buildpacks/rfcs/pull/23) |
There was a problem hiding this comment.
Would you mind clarifying why these aren't valid alternatives?
There was a problem hiding this comment.
i wouldn't say they aren't valid approaches. We just don't have support for them.
|
|
||
| 1. The lifecycle will compare the list of mixins to those provided by the stack using the `io.buildpacks.stack.mixins` label. | ||
| 1. If all mixin names are provided by the stack, no further action is required. | ||
| 1. If any requested mixin is not provided by the stack, the lifecycle will run the detect phase for all stackpacks defined in the builder. |
There was a problem hiding this comment.
I'm a bit confused - does this mean that we run detect twice? I thought stack packs were supposed to run before userspace buildpacks...
Signed-off-by: Joe Kutner <jpkutner@gmail.com>
|
It probably makes sense to hold this proposal until we decide on how the Lifecycle will (or will not) handle |
Signed-off-by: Joe Kutner <jpkutner@gmail.com> Co-authored-by: David Freilich <dfreilich@vmware.com>
|
@jkutner do you still want to keep this open? |
Readable