Move analyze phase before detect #135
Conversation
87f69a5 to
b98f971
Compare
Signed-off-by: Joe Kutner <jpkutner@gmail.com>
b98f971 to
0af5a0f
Compare
text/0000-prepare-phase.md
Outdated
| # What it is | ||
| [what-it-is]: #what-it-is | ||
|
|
||
| The prepare phase will run before all other phase, and prepare the execution environment for a buildpack build. This phase will have access to secrets and credentials used to access registries and other services. |
There was a problem hiding this comment.
"access to secrets and credentials used to access registries and other services"
Is this something that will happen throughout the lifecycle or just in prepare like export? Should this be defined as a special level of privilege?
There was a problem hiding this comment.
it happens in analyze, restore, and export (but not detect and build)
Signed-off-by: Joe Kutner <jpkutner@gmail.com> Co-authored-by: Terence Lee <hone02@gmail.com>
Signed-off-by: Joe Kutner <jpkutner@gmail.com>
Signed-off-by: Jesse Brown <jabrown85@gmail.com>
Signed-off-by: Jesse Brown <jabrown85@gmail.com>
Signed-off-by: Jesse Brown <jabrown85@gmail.com>
Signed-off-by: Jesse Brown <jabrown85@gmail.com>
| * Exit status | ||
| * Info-level logs to `stdout` | ||
| * Error-level logs to `stderr` | ||
| * Analysis metadata [`analyzed.toml`](https://github.com/buildpacks/spec/blob/main/platform.md#analyzedtoml-toml), including run-image information. |
There was a problem hiding this comment.
Does analyzer need to care about the cache at this stage?
There was a problem hiding this comment.
I don't think analyzer will need the cache now, actually. It is already omitted from the inputs here, but only by chance :)
There was a problem hiding this comment.
Well hmm.. maybe analyzer does want the cache-image. But maybe not the cache-dir. So it can validate the registry keychain earlier.
There was a problem hiding this comment.
I think this is tangential to this RFC, but maybe it's worth noting that this RFC exists: https://github.com/buildpacks/rfcs/pull/21/files#diff-588fc1758ea351208954c917064a1907620d2e7a5984cd07d433c55bcd683e9b. I don't think anything in this RFC contradicts the other one, just keeping context.
text/0000-move-analyze-phase.md
Outdated
|
|
||
| The analyze phase will now run before the detect phase. The analyze phase will have access to secrets and credentials used to access registries and other services, as it does today. Analyze will no longer require a [`group.toml`](https://github.com/buildpacks/spec/blob/main/platform.md#grouptoml-toml). It will do this by splitting off some of the responsibilites into the restore phase. | ||
|
|
||
| ## Responsibilities |
There was a problem hiding this comment.
It might be worth calling out that these are new responsibilities, vs. what the analyzer does currently.
Signed-off-by: Jesse Brown <jabrown85@gmail.com>
Signed-off-by: Jesse Brown <jabrown85@gmail.com>
|
@sclevine do these updates align with what you were thinking? |
We can add these in later or in another optional phase. Signed-off-by: Jesse Brown <jabrown85@gmail.com>
Signed-off-by: Jesse Brown <jabrown85@gmail.com>
| * [Stack buildpacks](https://github.com/buildpacks/rfcs/pull/111), which require a phase to read run-image mixins validation prior to detection | ||
| * Validating registry access for all images that are used can happen prior to `detector` or `builder` phases, providing faster failures for end users. | ||
|
|
||
| # What it is |
There was a problem hiding this comment.
Maybe it's worth adding in what Platform API we're going to introduce these changes.
In order to determine if cache should be restored/analyzed at all if the stack change. Future use. Signed-off-by: Jesse Brown <jabrown85@gmail.com>
This is a re-do of #505, porting to the recently updated main branch. [RFC](buildpacks/rfcs#135) [Spec PR](buildpacks/spec#197) Signed-off-by: Jesse Brown <jabrown85@gmail.com>
Run `analyzer` before `detector` [Related RFC](buildpacks/rfcs#135) [Spec PR](buildpacks/spec#197) Signed-off-by: Jesse Brown <jabrown85@gmail.com> Co-authored-by: Natalie Arellano <narellano@vmware.com> Co-authored-by: Yael Harel <yharel@vmware.com>
Readable