RFC for pack detect #308
RFC for pack detect #308
Conversation
|
Maintainers, As you review this RFC please queue up issues to be created using the following commands: Issues(none) |
Signed-off-by: Rashad Sirajudeen <rashad.20@cse.mrt.ac.lk>
Signed-off-by: Rashad Sirajudeen <rashad.20@cse.mrt.ac.lk>
natalieparellano
added
type/rfc
scope/team
There was a problem hiding this comment.
Thanks for kicking this off @rashadism! I would love to see this happen :)
|
Thank you @natalieparellano , will update on the stuff you pointed out. |
Signed-off-by: Rashad Sirajudeen <rashad.20@cse.mrt.ac.lk>
|
I opened a corresponding draft PR . @natalieparellano can u have a look |
|
@jjbustamante is going to steward this one :) |
nice, looking forward to it (: |
text/0000-my-feature.md
Outdated
| - The main use case of `pack build` is to create OCI images, and detect is just a binary in the lifecycle, so it doesn't make much sense to include it in there. | ||
| - To avoid making the mostly used `pack build` command overly complicated. | ||
|
|
||
| Also, instead of `pack detect`, something like `pack execute --phase detect` can also be done, where the user can select exclusively what phase they need to run. Can start by implementing just the `detect` phase. |
There was a problem hiding this comment.
This might be worth doing. It could be nice for integration testing purposes to be able to run just the build or just the generate phases of a buildpack. Not that we'd include those into this RFC, but this would leave the CLI open for that possibility.
When it comes to integration testing buildpacks with complicated build plans, right now, you have two choices:
- Don't integration test them.
- Supply all the buildpacks required to run the buildpack under test. That way all the set up and requirements for this buildpack are complete.
If we could run build or generate specifically, then that would open up the ability to mock out the requirements and run more focused, faster integration tests.
Anyway, that is all just to say I would be in support of this CLI invocation as it leaves open the possibility of running other phases directly.
There was a problem hiding this comment.
Yes, it looks like the better path to take
text/0000-my-feature.md
Outdated
| ||--run-image|string| | ||
| ||--uid|int| | ||
| ||--workspace|string| | ||
|
|
There was a problem hiding this comment.
What would be the plan for the exit code of this command?
I think we should specify this because it's likely that we'll build tooling around this to run tests. We want the exit code to signal errors and for it to be stable.
There was a problem hiding this comment.
If I understood your question correctly,
Ideally it should be 0 if a build plan selection is successful. In the case of failure, we can come up with some common cases and define it accordingly.
There was a problem hiding this comment.
Ok, yes. 0 for success and 1 for failure probably covers most of what is necessary. I'm not sure we need to define a bunch of non-zero exit codes. It does make me wonder what the lifecycle returns 🤔 Maybe we should just make sure the lifecycle exit code is returned from this command? I suspect we'd get good results that way and then this command would be inline with the platform spec.
There was a problem hiding this comment.
I think we also need to add some examples executions of the command with the expected output, that helps a little bit to understand better what is going to do and if we need to pay attention to some details.
Co-authored-by: Daniel Mikusa <dan@mikusa.com> Signed-off-by: Rashad Sirajudeen <rashadsirajudeen@gmail.com>
Signed-off-by: Rashad Sirajudeen <rashadsirajudeen@gmail.com>
Signed-off-by: Rashad Sirajudeen <rashadsirajudeen@gmail.com>
|
I think this one might be ready for another round of reviews. |
A basic implementation on
pack detect.Looking forward on getting feedback and improving on this and coming up with the best version of this, and implenenting this.