Add `--dry-run` option to pack commands

simonjjones commented 4 years ago

Description

I would like to validate the configuration and intended outcome of a command I plan to run without incurring the cost of executing against real code and resources

Proposed solution

Each pack command can be invoked with a --dry-run argument which:

validates the configuration
outputs any pack generated logs that would occur during a real execution
describes interactions that would happen with dependencies outside of pack (e.g. Invoke this lifecycle phase with these arguments)
exits with the exit code that would occur during a real execution (assuming interactions with external dependencies are successful)
outputs any other useful information depending on the subcommand being invoked

Describe alternatives you've considered

Consumers can currently parse help text to ensure particular commands and arguments or available in their version of pack, and assume their configuration will be successful
App developers with large apps, who might incur long waits for commands to run may use a smaller test app to validate commands

Additional context

[ ] This feature should be documented somewhere

dfreilich commented 4 years ago

Should this be supported for all commands, or only for some? For instance, pack version --dry-run wouldn't seem to add much value, while obviously pack build --dry-run or pack rebase --dry-run would.

jromero commented 4 years ago

Could you elaborate on "outputs any pack generated logs that would occur during a real execution"?

Thinking about something like pack build how would the output be generated if it's mostly output of executed buildpacks and from my understanding the buildpack's build binary wouldn't actually execute.

yaelharel commented 4 years ago

This is a really good idea! I agree with @dfreilich (https://github.com/buildpacks/pack/issues/681#issuecomment-641576328) that it's probably not necessary for all of the pack commands. Maybe it's worth being more specific and specifying the expected output of each command (AC with examples of each relevant command).

simonjjones commented 4 years ago

I think the stateless commands should still run, the solution would still be valid as there are no interactions with external dependencies in those cases.

josegonzalez commented 3 years ago

A pack detect or similar command (with optional json output?) would be pretty neat so that we can report to users what their apps look like before actually building it (useful for platform onboarding).

aemengo commented 3 years ago

@josegonzalez Agreed. This is an underlying premise with pack-interact-mode.

aemengo commented 3 years ago

@simonjjones @jromero @dfreilich Can we have a little more detail about what the original intent of --dry-run was?

@haliliceylan and I were following the thread and are lost. In the pack build case for example:

Does dry-run simply mean run the detect phase?
Just about every phase requires creating an ephemeral builder on the daemon, so does that count as "incurring the cost of executing against real code and resources"?
How we "exits with the exit code that would occur during a real execution"? Without actually executing?

natalieparellano commented 2 months ago

Blocked (or perhaps more accurately, superseded) by https://github.com/buildpacks/rfcs/pull/308

buildpacks / pack