From 1d98e4f55a53b942bf3d3acd4870d2a625667848 Mon Sep 17 00:00:00 2001 From: Rashad Sirajudeen Date: Thu, 15 Feb 2024 11:05:02 +0530 Subject: [PATCH 1/5] Initial draft, up for feedback --- text/0000-my-feature.md | 113 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 113 insertions(+) create mode 100644 text/0000-my-feature.md diff --git a/text/0000-my-feature.md b/text/0000-my-feature.md new file mode 100644 index 000000000..2fdca1454 --- /dev/null +++ b/text/0000-my-feature.md @@ -0,0 +1,113 @@ +# Meta +[meta]: #meta +- Name: Implementing pack detect command +- Start Date: 2024-02-15 +- Author(s): @rashadism +- Status: Draft +- RFC Pull Request: (leave blank) +- CNB Pull Request: (leave blank) +- CNB Issue: (leave blank) +- Supersedes: N/A + +# Summary +[summary]: #summary + +The `pack detect` command is introduced to the Cloud Native Buildpacks ecosystem, providing a way to run only the detect phase of the buildpack lifecycle. This feature enhances the developer experience by allowing them to quickly determine which buildpacks are relevant for their application without progressing through the entire build process. This was partially discussed in [issue #681](https://github.com/buildpacks/pack/issues/681) but the issue was about implementing a `dry-run` flag. With further discussion with @jjbustamante, decided to go forward with this as a new pack pack command rather than a flag. + +# Definitions +[definitions]: #definitions + +Make a list of the definitions that may be useful for those reviewing. Include phrases and words that buildpack authors or other interested parties may not be familiar with. + +# Motivation +[motivation]: #motivation + +- Simplify and streamline the build process by providing a targeted command for buildpack detection. +- Reduce build times by skipping unnecessary phases of the buildpack lifecycle. +- Enable developers to quickly identify which buildpacks are applicable to their application without waiting for the entire build process to complete, or having to `Ctrl+C` midway through. + +# What it is +[what-it-is]: #what-it-is + +This provides a high level overview of the feature. + +- Define any new terminology. +- Define the target persona: buildpack author, buildpack user, platform operator, platform implementor, and/or project contributor. +- Explaining the feature largely in terms of examples. +- If applicable, provide sample error messages, deprecation warnings, or migration guidance. +- If applicable, describe the differences between teaching this to existing users and new users. + +# How it Works +[how-it-works]: #how-it-works + +Ideally, the user should run something like `pack detect --path ./path/to/project --builder builder:name` and it should run only the detect binary in the lifecycle and output the logs / output of it. Preferrably, can also output the `group.toml` to a directory specified with `--detect-output-dir`. + +The following flags should be supported and they will work more or less like `pack build`. + +|Short|Long|type| +|----|-------------|----| +|-B |--builder|string| +|-b |--buildpack|strings| +|-r |--buildpack-registry|string| +|-e|--env|stringArray| +||--env-file|stringArray| +||--extension|strings| +|-h|--help| +|-p|--path|string| +||--post-buildpack|stringArray| +||--pre-buildpack|stringArray| +||--detect-output-dir|string| + +# Migration +[migration]: #migration + +This feature does not introduce any breaks to public APIs or compatibility. It provides additional functionality within the existing Cloud Native Buildpacks CLI tooling, enhancing the developer experience without requiring changes to existing workflows or configurations. + +# Drawbacks +[drawbacks]: #drawbacks + +Why should we *not* do this? + +# Alternatives +[alternatives]: #alternatives + +Initially thought of implementing this through something like `pack build --detect`. But after further discussion with @jjbustamante and for the following reasons, decided to do this functionality to a new command. +- 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. + +# Prior Art +[prior-art]: #prior-art + +This has been discussed in Issue #681 before, and looked like it was a long awaited feature and currently a few workarounds are being used to get this functionality. + +# Unresolved Questions +[unresolved-questions]: #unresolved-questions + +Fill after initial discussion + +# Spec. Changes (OPTIONAL) +[spec-changes]: #spec-changes +Since this is a new command, the functionality of this command will have to be amended to the spec / docs. + +# History +[history]: #history + + \ No newline at end of file From a7c216338203eb51abce7fd18bac7ec86fb1a22d Mon Sep 17 00:00:00 2001 From: Rashad Sirajudeen Date: Fri, 15 Mar 2024 11:35:58 +0530 Subject: [PATCH 2/5] Added reviewed changes Signed-off-by: Rashad Sirajudeen --- text/0000-my-feature.md | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/text/0000-my-feature.md b/text/0000-my-feature.md index 2fdca1454..a9435ffc8 100644 --- a/text/0000-my-feature.md +++ b/text/0000-my-feature.md @@ -40,7 +40,7 @@ This provides a high level overview of the feature. # How it Works [how-it-works]: #how-it-works -Ideally, the user should run something like `pack detect --path ./path/to/project --builder builder:name` and it should run only the detect binary in the lifecycle and output the logs / output of it. Preferrably, can also output the `group.toml` to a directory specified with `--detect-output-dir`. +Ideally, the user should run something like `pack detect --path ./path/to/project --builder builder:name` and it should run the analyze binary, followed by the detect binary in the lifecycle and output the logs / output of it. Preferrably, can also output the `group.toml` to a directory specified with `--detect-output-dir`. The reason to run the analyze binary is to get information about the run image that may impact the outcome of detect via CNB_TARGET_* environment variables. The following flags should be supported and they will work more or less like `pack build`. @@ -49,14 +49,24 @@ The following flags should be supported and they will work more or less like `pa |-B |--builder|string| |-b |--buildpack|strings| |-r |--buildpack-registry|string| +||--detect-output-dir|string| +|-d|--descriptor|string| +||--docker-host|string| |-e|--env|stringArray| ||--env-file|stringArray| ||--extension|strings| +||--gid|int| |-h|--help| +||--lifecycle-image|string| +||--network|string| |-p|--path|string| ||--post-buildpack|stringArray| ||--pre-buildpack|stringArray| -||--detect-output-dir|string| +||--pull-policy|string| +||--run-image|string| +||--uid|int| +||--workspace|string| + # Migration [migration]: #migration From 3ed07bdf3ec1934f0e468123f3f733f3becef07f Mon Sep 17 00:00:00 2001 From: Rashad Sirajudeen Date: Tue, 14 May 2024 10:03:00 +0530 Subject: [PATCH 3/5] Update text/0000-my-feature.md Co-authored-by: Daniel Mikusa Signed-off-by: Rashad Sirajudeen --- text/0000-my-feature.md | 1 + 1 file changed, 1 insertion(+) diff --git a/text/0000-my-feature.md b/text/0000-my-feature.md index a9435ffc8..6a9be7107 100644 --- a/text/0000-my-feature.md +++ b/text/0000-my-feature.md @@ -25,6 +25,7 @@ Make a list of the definitions that may be useful for those reviewing. Include p - Simplify and streamline the build process by providing a targeted command for buildpack detection. - Reduce build times by skipping unnecessary phases of the buildpack lifecycle. - Enable developers to quickly identify which buildpacks are applicable to their application without waiting for the entire build process to complete, or having to `Ctrl+C` midway through. +- Lighter-weight integration testing of the build plan. # What it is [what-it-is]: #what-it-is From 3e8c78ffc63b807737c3dafb2c1d1e4733194f55 Mon Sep 17 00:00:00 2001 From: Rashad Sirajudeen Date: Thu, 13 Jun 2024 19:51:12 +0530 Subject: [PATCH 4/5] fixed typo Signed-off-by: Rashad Sirajudeen --- text/0000-my-feature.md | 69 +++++++++++++++++++++++++---------------- 1 file changed, 42 insertions(+), 27 deletions(-) diff --git a/text/0000-my-feature.md b/text/0000-my-feature.md index 6a9be7107..fe465170e 100644 --- a/text/0000-my-feature.md +++ b/text/0000-my-feature.md @@ -1,5 +1,7 @@ # Meta + [meta]: #meta + - Name: Implementing pack detect command - Start Date: 2024-02-15 - Author(s): @rashadism @@ -10,16 +12,19 @@ - Supersedes: N/A # Summary + [summary]: #summary -The `pack detect` command is introduced to the Cloud Native Buildpacks ecosystem, providing a way to run only the detect phase of the buildpack lifecycle. This feature enhances the developer experience by allowing them to quickly determine which buildpacks are relevant for their application without progressing through the entire build process. This was partially discussed in [issue #681](https://github.com/buildpacks/pack/issues/681) but the issue was about implementing a `dry-run` flag. With further discussion with @jjbustamante, decided to go forward with this as a new pack pack command rather than a flag. +The `pack detect` command is introduced to the Cloud Native Buildpacks ecosystem, providing a way to run only the detect phase of the buildpack lifecycle. This feature enhances the developer experience by allowing them to quickly determine which buildpacks are relevant for their application without progressing through the entire build process. This was partially discussed in [issue #681](https://github.com/buildpacks/pack/issues/681) but the issue was about implementing a `dry-run` flag. With further discussion with @jjbustamante, decided to go forward with this as a new `pack detect` command rather than a flag. # Definitions + [definitions]: #definitions Make a list of the definitions that may be useful for those reviewing. Include phrases and words that buildpack authors or other interested parties may not be familiar with. # Motivation + [motivation]: #motivation - Simplify and streamline the build process by providing a targeted command for buildpack detection. @@ -28,6 +33,7 @@ Make a list of the definitions that may be useful for those reviewing. Include p - Lighter-weight integration testing of the build plan. # What it is + [what-it-is]: #what-it-is This provides a high level overview of the feature. @@ -39,70 +45,79 @@ This provides a high level overview of the feature. - If applicable, describe the differences between teaching this to existing users and new users. # How it Works + [how-it-works]: #how-it-works -Ideally, the user should run something like `pack detect --path ./path/to/project --builder builder:name` and it should run the analyze binary, followed by the detect binary in the lifecycle and output the logs / output of it. Preferrably, can also output the `group.toml` to a directory specified with `--detect-output-dir`. The reason to run the analyze binary is to get information about the run image that may impact the outcome of detect via CNB_TARGET_* environment variables. +Ideally, the user should run something like `pack detect --path ./path/to/project --builder builder:name` and it should run the analyze binary, followed by the detect binary in the lifecycle and output the logs / output of it. Preferrably, can also output the `group.toml` to a directory specified with `--detect-output-dir`. The reason to run the analyze binary is to get information about the run image that may impact the outcome of detect via CNB*TARGET*\* environment variables. The following flags should be supported and they will work more or less like `pack build`. -|Short|Long|type| -|----|-------------|----| -|-B |--builder|string| -|-b |--buildpack|strings| -|-r |--buildpack-registry|string| -||--detect-output-dir|string| -|-d|--descriptor|string| -||--docker-host|string| -|-e|--env|stringArray| -||--env-file|stringArray| -||--extension|strings| -||--gid|int| -|-h|--help| -||--lifecycle-image|string| -||--network|string| -|-p|--path|string| -||--post-buildpack|stringArray| -||--pre-buildpack|stringArray| -||--pull-policy|string| -||--run-image|string| -||--uid|int| -||--workspace|string| - +| Short | Long | type | +| ----- | -------------------- | ----------- | +| -B | --builder | string | +| -b | --buildpack | strings | +| -r | --buildpack-registry | string | +| | --detect-output-dir | string | +| -d | --descriptor | string | +| | --docker-host | string | +| -e | --env | stringArray | +| | --env-file | stringArray | +| | --extension | strings | +| | --gid | int | +| -h | --help | +| | --lifecycle-image | string | +| | --network | string | +| -p | --path | string | +| | --post-buildpack | stringArray | +| | --pre-buildpack | stringArray | +| | --pull-policy | string | +| | --run-image | string | +| | --uid | int | +| | --workspace | string | # Migration + [migration]: #migration This feature does not introduce any breaks to public APIs or compatibility. It provides additional functionality within the existing Cloud Native Buildpacks CLI tooling, enhancing the developer experience without requiring changes to existing workflows or configurations. # Drawbacks + [drawbacks]: #drawbacks -Why should we *not* do this? +Why should we _not_ do this? # Alternatives + [alternatives]: #alternatives Initially thought of implementing this through something like `pack build --detect`. But after further discussion with @jjbustamante and for the following reasons, decided to do this functionality to a new command. + - 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. # Prior Art + [prior-art]: #prior-art This has been discussed in Issue #681 before, and looked like it was a long awaited feature and currently a few workarounds are being used to get this functionality. # Unresolved Questions + [unresolved-questions]: #unresolved-questions Fill after initial discussion # Spec. Changes (OPTIONAL) + [spec-changes]: #spec-changes + Since this is a new command, the functionality of this command will have to be amended to the spec / docs. # History + [history]: #history \ No newline at end of file +---> From 572bbcd8d4abd68719b155d928db83f01121b3e5 Mon Sep 17 00:00:00 2001 From: Rashad Sirajudeen Date: Fri, 14 Jun 2024 10:56:13 +0530 Subject: [PATCH 5/5] Updated with changes from feedback Signed-off-by: Rashad Sirajudeen --- text/0000-my-feature.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/text/0000-my-feature.md b/text/0000-my-feature.md index fe465170e..085539aa1 100644 --- a/text/0000-my-feature.md +++ b/text/0000-my-feature.md @@ -15,7 +15,7 @@ [summary]: #summary -The `pack detect` command is introduced to the Cloud Native Buildpacks ecosystem, providing a way to run only the detect phase of the buildpack lifecycle. This feature enhances the developer experience by allowing them to quickly determine which buildpacks are relevant for their application without progressing through the entire build process. This was partially discussed in [issue #681](https://github.com/buildpacks/pack/issues/681) but the issue was about implementing a `dry-run` flag. With further discussion with @jjbustamante, decided to go forward with this as a new `pack detect` command rather than a flag. +The `pack execute` command is introduced to the Cloud Native Buildpacks ecosystem, providing a way to run only selected phases of the buildpack lifecycle. For the moment, only `detect` will be implemented, which will be invoked through `pack execute detect`.This feature enhances the developer experience by allowing them to quickly determine which buildpacks are relevant for their application without progressing through the entire build process. This was partially discussed in [issue #681](https://github.com/buildpacks/pack/issues/681) but the issue was about implementing a `dry-run` flag. With further discussion with @jjbustamante, decided to go forward with this as a new `pack detect` command rather than a flag, and after further review it will be implemented as `pack execute detect`. # Definitions @@ -27,6 +27,7 @@ Make a list of the definitions that may be useful for those reviewing. Include p [motivation]: #motivation +- Enable the running of selected phases of buildpacks upon need. - Simplify and streamline the build process by providing a targeted command for buildpack detection. - Reduce build times by skipping unnecessary phases of the buildpack lifecycle. - Enable developers to quickly identify which buildpacks are applicable to their application without waiting for the entire build process to complete, or having to `Ctrl+C` midway through. @@ -48,7 +49,7 @@ This provides a high level overview of the feature. [how-it-works]: #how-it-works -Ideally, the user should run something like `pack detect --path ./path/to/project --builder builder:name` and it should run the analyze binary, followed by the detect binary in the lifecycle and output the logs / output of it. Preferrably, can also output the `group.toml` to a directory specified with `--detect-output-dir`. The reason to run the analyze binary is to get information about the run image that may impact the outcome of detect via CNB*TARGET*\* environment variables. +Ideally, the user should run something like `pack execute detect --path ./path/to/project --builder builder:name` and it should run the analyze binary, followed by the detect binary in the lifecycle and output the logs / output of it. This also copies `group.toml` to a directory specified with `--detect-output-dir`, if the flag was enabled. The reason to run the analyze binary is to get information about the run image that may impact the outcome of detect via CNB*TARGET*\* environment variables. The following flags should be supported and they will work more or less like `pack build`. @@ -91,13 +92,11 @@ Why should we _not_ do this? [alternatives]: #alternatives -Initially thought of implementing this through something like `pack build --detect`. But after further discussion with @jjbustamante and for the following reasons, decided to do this functionality to a new command. +Initially thought of implementing this through something like `pack build --detect`. But after further discussion with @jjbustamante and for the following reasons, decided to do this functionality to a new command. Upon further review, this will be implemented as `pack execute detect ..` - 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. - # Prior Art [prior-art]: #prior-art