Add more details to pack inspect-builder

[ekcasey]

Default Builder (Case #1)

Given I have a the default builder image packs/sample
When I run pack inspect-builder (no positional arguments)
Then I see the following output:

Inspecting default builder: packs/samples

Remote
--------

Stack: io.buildpacks.stacks.bionic

Run Images:
  example.com/packs1/run (user-configured)
  example.com/packs2/run (user-configured)
  gcr.io/packs2/run (user-configured)
  packs/run
  gcr.io/packs/run

Buildpacks:
ID                           VERSION              LATEST
io.buildpacks.nodejs         0.0.1                true
io.buildpacks.java           0.0.1                true

Detection Order:
Group #1:
  io.buildpacks.nodejs@latest
Group #2:
  io.buildpacks.java@latest

Local
-----

Stack: io.buildpacks.stacks.bionic

Run Images:
  example.com/packs1/run (user-configured)
  example.com/packs2/run (user-configured)
  gcr.io/packs2/run (user-configured)
  packs/run
  gcr.io/packs/run

Buildpacks:
ID                           VERSION              LATEST
io.buildpacks.nodejs         0.0.1                true
io.buildpacks.java           0.0.1                true

Detection Order:
Group #1:
  io.buildpacks.nodejs@latest
Group #2:
  io.buildpacks.java@latest

Provided Builder

Given I have a builder image my/builder for stack my.stack with buildpack [email protected] (latest true), [email protected], and [email protected] and the following order.toml

[[groups]]
  [[groups.buildpacks]]
    id = "bp.1"
    version = "1.0.1"

  [[groups.buildpacks]]
    id = "bp.2"
    version = "1.0.2"

[[groups]]
  [[groups.buildpacks]]
    id = "bp.1"
    version = "1.0.1"

When I run pack inspect-builder my/builder
Then I see the contents of my/builder formatted as above
Except I see the following header:

Inspecting builder: my/builder

And, For Example the buildpacks are detection order sections are formatted as

Buildpacks:
ID        VERSION      LATEST
bp.1      1.0.1        true
bp.2      1.0.2
bp.3      1.0.3

Detection Order:
Group #1:
  [email protected]
  [email protected]
Group #2:
  [email protected]

Invalid Builders

Given I have a builder image bad/builder without a io.buildpacks.stack.id label
When I run pack inspect-builder bad/builder
Then I see the following output

Inspecting builder:  bad/builder

Error: `packs/samples` is an invalid builder because it is missing a `io.buildpacks.stack.id` label

Given I have a builder image empty/builder without any buildpacks
When I run pack inspect-builder empty/builder
Then I see the following header:

Inspecting builder: empty/builder

Warning: 'empty/builder' has no buildpacks
         Users must supply buildpacks from the host machine.

...

Given I have a builder image no-order/builder without any buildpacks
When I run pack inspect-builder no-order/builder
Then I see the following header:

Inspecting builder: no-order/builder

Warning: 'no-order/builder' does not specify detection order. 
         Users must build with explicitly-specified buildpacks.

...

Notes

• Do not error if buildpack metadata is missing (for backwards-compatibility)
• Builder metadata label should be io.buildpacks.builder.metadata (not io.buildpacks.pack.*). Update this label on the samples, but don't add all the contents to the samples. We will play the pack create-builder + samples story to fix that.

[ekcasey]

We could use this opportunity to provide warnings if the order.toml references missing buildpacks or things like that. But that might be overkill.

[dgodd]

@ekcasey @ssisil Should we distinguish between local and remote builder images? Should this just be local? Should there be a pull / no-pull.

[ssisil]

@dgodd - I would expect to be able to inspect local and remote. Do we need to pull the builder image to inspect it or can we just do it remotely? I could see the use case where I inspect a remote builder before I actually decide to use it locally, therefore not wanting to pull it.

[dgodd]

@ssisil Emily and I decided we thought always inspect the local image, and then add --no-pull such that we do a pull before inspecting (unless --no-pull) is specified. This makes things similar enough to build etc....

[sclevine]

Updated to:

• normalize formatting
• cover more cases
• prevent line overflow with 40+ buildpacks in a group

[djoyahoy]

@mgibson1121 We also noticed that inspect-builder does not prompt for a default builder if you don't have one set, resulting in weird output. We'll cover that when we address this story too.

[mgibson1121]

Test with the following to see buildpacks

// Do once
gcloud auth login
gcloud components install docker-credential-gcr
docker-credential-gcr configure-docker

// Do if you want to see info on a local builder too (may want to test both with and without this step)
docker pull gcr.io/cncf-buildpacks-ci/packs/samples@sha256:95b223a912a33b6ad4786351ee4265d40460d0e94cf13d9474846fbba5104e5f

// Inspect
pack inspect-builder gcr.io/cncf-buildpacks-ci/packs/samples@sha256:95b223a912a33b6ad4786351ee4265d40460d0e94cf13d9474846fbba5104e5f

[mgibson1121]

@djoyahoy Ok, will move back to in progress and apply the rejected label.

[mgibson1121]

Using builder @djoyahoy provided I can now see the buildpack groups. Accepting this story.

[mgibson1121]

@djoyahoy @ekcasey I can no longer move cards around on the board (maybe due to permission stuff from last week?) Can one of you move this to the 0.1.0 release column?