Add --dry-run option to pack commands

[simonjjones]

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]

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]

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]

This is a really good idea!
I agree with @dfreilich (#681 (comment)) 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]

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]

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]

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

[aemengo]

@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]

Blocked (or perhaps more accurately, superseded) by buildpacks/rfcs#308