Add prepare operation RFC #202
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) |
There was a problem hiding this comment.
FYI We have implementations for some of those preparer functionality in the Piper cnbBuild step and utility package.
E.g. include/exclude handling, buildpack downloads (from url or via buildpack registry), etc.
I guess we could provide those if this RFC was accepted.
Signed-off-by: Javier Romero <rjavier@vmware.com>
jromero
force-pushed
the
rfc/prepare-operation
branch
from
1a4172a
to
8fc7a70
Compare
Signed-off-by: Javier Romero <rjavier@vmware.com>
Signed-off-by: Javier Romero <rjavier@vmware.com>
|
Based on further conversations of additional "operations" such as prepare (this RFC), publish, and cosign we are considering moving forward with an "implement first and standardize later" strategy. This approach was decided because it heavily relies on the willingness of individual platforms to incorporate such operations. As a project, we think that by providing the utilities and "example" implementation through platforms we maintain, such as Pack and Tekon Tasks, can prove the value of such individual reusable components and operations. The hope is that, with due, time truly desired functionality is naturally promoted from an example, to convention, to specification. @jjbustamante + @samj1912 please correct me if my understanding is incorrect. |
|
|
||
| #### Remove `io.buildpacks` namespace | ||
|
|
||
| We'll want to remove the `io.buildpacks` namespace since it will be versioned seperate from the project descriptor. |
There was a problem hiding this comment.
I guess I understand the need for this but I also find the idea of another spec somewhat confusing. Unfortunately I don't have any constructive suggestions to offer.
|
|
||
| > This would be useful for builder providers or platform implementers to not have to develop standard functionality. | ||
|
|
||
| The default implementation COULD take care of applying the following configuration: |
There was a problem hiding this comment.
To link up some discussion re: https://github.com/buildpacks/spec/pull/288, it could also download a run-image sbom if provided as a label pointing to a layer or a cosign-attached image manifest.
|
Update: a new repository with this work has been started here: https://github.com/jromero/cnb-prepare |
1 similar comment
|
Update: a new repository with this work has been started here: https://github.com/jromero/cnb-prepare |
|
Hi @jromero, in Shipwright, we are using the lifecycle methods and therefore bypass pack, similar as the Tekton catalog task. Your prepare operation is quite interesting. Is this something you are still looking at? |
|
I'd love to see this move forward |
Readable
Change Log
2022-02-22 (94e3180, d02754f)
2022-02-10 (8fc7a70)
io.buildpacksnamespace an independent schema version2022-02-07 (99fc145)