Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC for pack detect #308

Merged
merged 5 commits into from
Aug 22, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
138 changes: 138 additions & 0 deletions text/0000-my-feature.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,138 @@
# Meta

[meta]: #meta

- Name: Implementing pack detect command
- Start Date: 2024-02-15
- Author(s): @rashadism
- Status: Draft <!-- Acceptable values: Draft, Approved, On Hold, Superseded -->
- RFC Pull Request: (leave blank)
- CNB Pull Request: (leave blank)
- CNB Issue: (leave blank)
- Supersedes: N/A

# Summary

[summary]: #summary

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

[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

- 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.
rashadism marked this conversation as resolved.
Show resolved Hide resolved
- 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.

- 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 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`.

| 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?

# 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. 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.

# 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

<!--
## Amended
### Meta
[meta-1]: #meta-1
- Name: (fill in the amendment name: Variable Rename)
- Start Date: (fill in today's date: YYYY-MM-DD)
- Author(s): (Github usernames)
- Amendment Pull Request: (leave blank)

### Summary

A brief description of the changes.

### Motivation

Why was this amendment necessary?
--->
Loading