WHEN I run pack update-stack my.custom.stack.id --run-image my-org/run --build-image my-org/build
THEN the stack with the ID my.custom.stack.id will update the existing images for the stack in the config.toml with the ones specified
AND the user will see the following message "<stack id> successfully updated."

Notes

• Multiple run and build images can be provided
• If stack id does not exist - return the following message "<stack id> does not exist. Please run pack update-stack with an existing stack ID."

GIVEN I am building an image with pack build
WHEN the build completes successfully
THEN I will see a SHA representing the image returned in the command line in the following format :

Image: example.com/myorg/repo@434a7be...

NOTE: Only do this for publish

Scenario : Specify buildpack

GIVEN I am using CF v2b buildpack to build my application
WHEN I specify pack cf-build --path <app-dir> [--stack <stack-name>]
THEN I will see a successful build of my application

To shorten dev cycles when developing a buildpack I have found it useful (essential) to be able to run the detect and build locally. In doing that I found that many existing buildpacks (ones built with libpack probably) make assumptions about env vars, so they barf, for example, if PACK_STACK_ID is not set. That's useful to know (and not obvious from any documentation I managed to grok), but it means I can't use PACK_STACK_ID as a signal that I'm running in pack (or some kind of platform). I have adopted PACK_PLAN_PATH as such a signal (it's not mandatory for any of the packs that I have tried, and it is always there when running in pack), but it might not be stable. So what I need, I think, is something that is "just there", and doesn't mean anything other than that we are running in pack build.

As a buildpack developer I want to create a builder image on top of a custom stack so that I can create builder images specific to my platform

Creating a builder with a custom Stack

It respects the -s or --stack flag

Given I have created a ~/.pack/config.toml file with the following contents

[[stacks]]
id = “my.custom.stack”
run-images = ["my-org/run", "registry2.org/my-org/run" ]
build-images = ["my-org/build"]

When I run pack create-builder my-org/builder -s "my.custom-stack" -b builder.toml
Then an image my-org/builder is created using my-org/build as the base image
And The following label is added to the builder image io.buildpacks.stack.id=my.custom.stack

It respects the default stack field

Given I have created a ~/.pack/config.toml file with the following contents

default-stack-id = “my.custom.stack”
[[stacks]]
id = “my.custom.stack”
run-images = ["my-org/run", "registry2.org/my-org/run" ]
build-images = ["my-org/build"]

When I run pack create-builder my-org/builder -b builder.toml
Then an image my-org/builder is created using my-org/build as the base image

Building with a custom stack

Given I have created my-org/builder using my.custom.stack
When I run pack build --builder my-org/builder my-org/app
Then my-org/app image is generated using my-org/run as the base image

It defaults to the run-image with a registry matching the app image

Given I have added new default stack to my config.toml file

[[stacks]]
id = “my.custom.stack”
run-images = ["my-org/run", "registry2.org/my-org/run" ]
build-images = ["my-org/build"]

Given I have created my-org/builder using my.custom.stack
When I run pack build --builder my-org/builder registry2.org/my-org/app
Then an app image registry2.org/my-org/app is generated using registry2.org/my-org/run as the base image

Allows custom run-images but errors on stack mismatch

Given I have created my-org/builder using my.custom.stack
When I run pack build --builder my-org/builder registry2.org/my-org/app --run-image some-org/bad-run-image
Where some-org/bad-run-image no io.buildpacks.stack.id label or a io.buildpacks.stack.id label who's value does not match my.custom.stack
Then it fails and prints a helpful error message

• run-images with correct stack labels are allowed, even if they are not included in the config.toml file

Recording default stacks

Whenever pack build or pack create-builder is run, any new stacks are added to the config.toml if they do not exist already and bionic is set as the default stack if none is specified.

Note

• For domain matching look at domain matching in img package

https://github.com/buildpack/pack/blob/master/build.go#L22 references "github.com/buildpack/packs/img" but https://github.com/buildpack/packs does not have that subfolder. Something I did wrong?

GIVEN I have access to a custom builder image
WHEN I run pack set-default-builder <builder img>
THEN my pack cli will default to using that builder image moving forward

It's nice to know what you are running,

In order to help the community have visibility into the project, it's important to publicize the goals, milestones (bonus for a non-binding schedule), and progress of the pack CLI as it moves towards 1.0.

Still try to locate the source of the base image stacks and buildpacks are setup on (still looks like fulk blown Ubuntu trusty). I would appreciate to make use of distroless (how low can you go) base and only pull in necessary stuff needed for the specific target runtime.
You may check https://github.com/GoogleContainerTools/distroless

Pull images unless --no-pull is specified

Exception: During build we should not pull run image if published

it'd be nice! I can try to introduce you to people at Microsoft if you need resources.

This command defined within the README file is not correct

./pack build myorg/myapp -p fixtures/node_app --detect-image packsdev/v3:detect --publish

and should include accetpance folder :

./pack build myorg/myapp -p acceptance/fixtures/node_app --detect-image packsdev/v3:detect --publish

While pack is running I often see CPU utilization above 400%. Most of the heavy lifting should be happening within the docker daemon. What is pack doing?

I'm using a custom build from master (eb7d55b):

• mac OS 10.14
• go version go1.11 darwin/amd64
• GO111MODULE=on go build -o pack ./cmd/pack

Acceptance Criteria

Case 1
When I build an app image using pack build without publishing it
And I rebuild the same app image without publishing it
Then The second build is always as fast or faster compared to the first build

Case 3
When I build an app image using pack build and publish it using --publish
And I rebuild the same app image and publish it
Then The second build is always as fast or faster compared to the first build

Case 3
When I build an app image using pack build without publishing it
Then It is as fast or faster compared to publishing it with --publish

GIVEN I have built an image using a buildpack
WHEN I rebuild the source code with the buildpack
THEN the buildpack will used cached build dependencies to decrease the build time

Do we have to run a specific command in order to grab the vendor dependencies as this command fails ?

go build ./cmd/pack
build.go:12:2: cannot find package "github.com/BurntSushi/toml" in any of:
        /usr/local/opt/go/libexec/src/github.com/BurntSushi/toml (from $GOROOT)
        /Users/dabou/Code/go-workspace/src/github.com/BurntSushi/toml (from $GOPATH)
analyzer.go:6:2: cannot find package "github.com/buildpack/lifecycle" in any of:
        /usr/local/opt/go/libexec/src/github.com/buildpack/lifecycle (from $GOROOT)
        /Users/dabou/Code/go-workspace/src/github.com/buildpack/lifecycle (from $GOPATH)
analyzer.go:7:2: cannot find package "github.com/buildpack/packs" in any of:
        /usr/local/opt/go/libexec/src/github.com/buildpack/packs (from $GOROOT)
        /Users/dabou/Code/go-workspace/src/github.com/buildpack/packs (from $GOPATH)
exporter.go:9:2: cannot find package "github.com/buildpack/packs/img" in any of:
        /usr/local/opt/go/libexec/src/github.com/buildpack/packs/img (from $GOROOT)
        /Users/dabou/Code/go-workspace/src/github.com/buildpack/packs/img (from $GOPATH)
utils.go:6:2: cannot find package "github.com/google/go-containerregistry/pkg/v1" in any of:
        /usr/local/opt/go/libexec/src/github.com/google/go-containerregistry/pkg/v1 (from $GOROOT)
        /Users/dabou/Code/go-workspace/src/github.com/google/go-containerregistry/pkg/v1 (from $GOPATH)
build.go:14:2: cannot find package "github.com/google/uuid" in any of:
        /usr/local/opt/go/libexec/src/github.com/google/uuid (from $GOROOT)
        /Users/dabou/Code/go-workspace/src/github.com/google/uuid (from $GOPATH)
cmd/pack/main.go:7:2: cannot find package "github.com/spf13/cobra" in any of:
        /usr/local/opt/go/libexec/src/github.com/spf13/cobra (from $GOROOT)
        /Users/dabou/Code/go-workspace/src/github.com/spf13/cobra (from $GOPATH)

GIVEN I am a developer creating a CLI that will leverage Cloud Native Buildpacks
WHEN I integrate with the pack build command
THEN I will use the Go Client API to include that functionality in my CLI

GIVEN I have v3 buildpack(s) that exists on my local machine
WHEN I run pack build <app img> --buildpack <buildpack ID> --path <path to source code>
THEN my application will build using the custom buildpack
AND return the following image sha

Image: example.com/myorg/repo@434a7be...

Notes

• ID of an existing buildpack supported in default builder - ie. io.buildpacks.java, io.buildpacks.ruby, io.buildpacks.go, etc
• Can use -b as shorthand for --buildpack
• Can pass in multiple -b or --buildpack and the buildpacks will be run in that order
• Use builder specified with --builder. If not specified, use default builder for default stack
• No stack selection is possible yet
• Provide new order.toml with single group of specified buildpacks

default-stack-id = "io.buildpacks.stacks.scott-trusty"

[[stacks]]
id = "io.buildpacks.stacks.scott-trusty"
build-images = ["ssisil/build:trusty2"]
run-images = ["ssisil/run:trusty2"]

[[stacks]]
id = "org.cloudfoundry.stacks.cflinuxfs3"
build-images = ["cfbuildpacks/cflinuxfs3-cnb-experimental:build"]
run-images = ["cfbuildpacks/cflinuxfs3-cnb-experimental:run"]

[[stacks]]
id = "io.buildpacks.stacks.bionic"
build-images = ["packs/build"]
run-images = ["packs/run"]

TBD

Thus repository becomes build-image and run-image

NOTE: make sure it doesn't use stack anywhere as text

Given that its not a failure in the usage, we probably don't need to output the entire help content:

$ pack build --path . app/seamstress:latest
*** PULLING BUILDER IMAGE LOCALLY:
*** DETECTING:
2018/10/03 22:14:06 Group: Sample Node.js Buildpack: fail
2018/10/03 22:14:06 Group: Sample Java Buildpack: error (1)
2018/10/03 22:14:06 Error: failed to detect
Error: run detect container: failed with status code: 6
Usage:
  pack build <image-name> [flags]

Flags:
      --builder string     builder (default "packs/samples")
  -h, --help               help for build
      --no-pull            don't pull images before use
  -p, --path string        path to app dir (default "/Users/jose/Dropbox/src/seatgeek/seamstress")
      --publish            publish to registry
      --run-image string   run image (default "packs/run")

Scenario : Buildpack version is not set as latest in builder.toml
GIVEN I have a CNB with an ID of Z and a version set to X
AND I have a CNB with an ID of Z and a version set to Y
AND neither are set as the latest in the [[buildpacks]] section of my builder.toml
WHEN I run `pack build --builder --buildpack Z
THEN the build should fail
AND the following message should be displayed to the developer

<image name> failed to build.  <my builder> has multiple versions of buildpack Z, please provide the specific version you want to use. 

Deliverables
Each push to github should generate three binaries:

• pack-[7-char-sha]-macos
• pack-[7-char-sha]-linux
• pack-[7-char-sha]-windows

These binaries should be publicly hosted in a google cloud bucket with a dedicated account for this joint effort.

These are too slow on mac. Either stream to a file at start/finish (for the cache perhaps?), or use a container mount (for /launch, /workspace).

Notes

• Multitenancy not in scope

GIVEN I have multiple versions of a buildpack
WHEN I update provide "latest=true" for the buildpack in the buildpacks list in the builder.toml when i run pack create-builder
THEN a relative symlink will be created for the corresponding version and the buildpack marked as latest

Expected behavior:
I can use go get github.com/buildpack/pack to fetch source

Observed behavior:
Failure when running, apparently due to mismatched imported, vendored deps

$ docker run -it golang:1.11.1
root@2b66f88f9793:/go# go get github.com/buildpack/pack
# github.com/buildpack/pack/image
src/github.com/buildpack/pack/image/image.go:28:2: cannot use origImage (type "github.com/buildpack/lifecycle/vendor/github.com/google/go-containerregistry/pkg/v1".Image) as type "github.com/google/go-containerregistry/pkg/v1".Image in return argument:
        "github.com/buildpack/lifecycle/vendor/github.com/google/go-containerregistry/pkg/v1".Image does not implement "github.com/google/go-containerregistry/pkg/v1".Image (wrong type for BlobSet method)
                have BlobSet() (map["github.com/buildpack/lifecycle/vendor/github.com/google/go-containerregistry/pkg/v1".Hash]struct {}, error)
                want BlobSet() (map["github.com/google/go-containerregistry/pkg/v1".Hash]struct {}, error)

As a app developer I want to export my newly built image to a registry so that I can deploy it into k8s

Case 1 (publish)

GIVEN I have an app in <app-dir>
WHEN I run

pack build <registry>/<repo-name>:<tag-name (optional)> --path <app-dir> --publish

THEN my image is exported to the in the repository

Case 2 (development)

GIVEN I have an app in <app-dir>
WHEN I run

pack build <registry>/<repo-name>:<tag-name (optional)>  --path <app-dir>

THEN my image is exported to the daemon in the repository

WHEN I run pack set-default-stack my.custom.stack.id
THEN the stack ID passed in will be set as the default in the config.toml file
AND the following message will be displayed to the user

my.custom.stack.id is now the default stack

Notes

• If the stack ID passed in does not exist then return the following message <stack ID> does not exist. Please pass in a valid stack ID.

GIVEN I have a 1 to many V3 buildpacks in a that has the following structure :

buildpacks dir
|__io.buildpacks.nodejs
    |__v1.0.0
    |__v1.0.1
    |__latest -> v1.0.1 
|__io.buildpacks.java
    |__v2.0.5
    |__latest -> v2.0.5
|__order.toml

AND order.toml provides buildpack groups, build and run image names
WHEN I run pack create <detect image> --path <buildpacks dir> --base-image <base image>
THEN detect image will be created
AND all the build and run images will be created
AND the following will be displayed to the user

Image: example.com/myorg/repo@434a7be...

Tip: Run `pack build <image name> --detect-image <detect image> --path <app source code>` to use this buildpack

Note

• Determine if latest dir can be an actual folder or needs to be a symlink to a specific version
  ANSWER: must be symlink
• Add --publish flag to support publishing image to remote registry

Defaults

• --path = .
• --base-image = packs/v3

When we issue this command ./pack build myorg/myapp -p acceptance/fixtures/node_app --publish

then the following error is reported

Error: failed to get image for packs/v3:run

even if we try to install manually using docker pull the image(s)

Full log

./pack build myorg/myapp -p acceptance/fixtures/node_app --publish                                  
*** DETECTING:
2018/08/23 07:43:34 Group: Sample Node.js Buildpack: pass
*** ANALYZING: Reading information from previous image for possible re-use
*** BUILDING:
Unable to find image 'packs/v3:build' locally
Trying to pull repository docker.io/packs/v3 ... 
build: Pulling from docker.io/packs/v3
c64513b74145: Already exists 
01b8b12bad90: Already exists 
c5d85cf7a05f: Already exists 
b6b268720157: Already exists 
e12192999ff1: Already exists 
9ec0afc3dd8c: Already exists 
8a8b744b79d4: Already exists 
c8c61c40292b: Already exists 
bfbfbd08c7bd: Already exists 
a1ecf4c48a82: Already exists 
9b4930b9f540: Already exists 
f0359eb7d8f7: Already exists 
3265a1e603ff: Pull complete 
8084fd95401b: Pull complete 
94bcec7355fb: Pull complete 
8264c669f1cf: Pull complete 
Digest: sha256:0358de438433568b3678bef43170795de8b9cfa174ecfc8131e625b96a48cd7c
Status: Downloaded newer image for docker.io/packs/v3:build
[email protected] /launch/app/node_modules/express
[email protected] /launch/app/node_modules/express/node_modules/accepts
[email protected] /launch/app/node_modules/express/node_modules/mime-types
[email protected] /launch/app/node_modules/express/node_modules/mime-db
[email protected] /launch/app/node_modules/express/node_modules/negotiator
[email protected] /launch/app/node_modules/express/node_modules/array-flatten
[email protected] /launch/app/node_modules/express/node_modules/body-parser
[email protected] /launch/app/node_modules/express/node_modules/bytes
[email protected] /launch/app/node_modules/express/node_modules/content-type
[email protected] /launch/app/node_modules/express/node_modules/debug
[email protected] /launch/app/node_modules/express/node_modules/ms
[email protected] /launch/app/node_modules/express/node_modules/depd
[email protected] /launch/app/node_modules/express/node_modules/http-errors
[email protected] /launch/app/node_modules/express/node_modules/inherits
[email protected] /launch/app/node_modules/express/node_modules/setprototypeof
[email protected] /launch/app/node_modules/express/node_modules/statuses
[email protected] /launch/app/node_modules/express/node_modules/iconv-lite
[email protected] /launch/app/node_modules/express/node_modules/on-finished
[email protected] /launch/app/node_modules/express/node_modules/ee-first
[email protected] /launch/app/node_modules/express/node_modules/qs
[email protected] /launch/app/node_modules/express/node_modules/raw-body
[email protected] /launch/app/node_modules/express/node_modules/raw-body/node_modules/http-errors
[email protected] /launch/app/node_modules/express/node_modules/raw-body/node_modules/depd
[email protected] /launch/app/node_modules/express/node_modules/raw-body/node_modules/setprototypeof
[email protected] /launch/app/node_modules/express/node_modules/unpipe
[email protected] /launch/app/node_modules/express/node_modules/type-is
[email protected] /launch/app/node_modules/express/node_modules/media-typer
[email protected] /launch/app/node_modules/express/node_modules/content-disposition
[email protected] /launch/app/node_modules/express/node_modules/cookie
[email protected] /launch/app/node_modules/express/node_modules/cookie-signature
[email protected] /launch/app/node_modules/express/node_modules/encodeurl
[email protected] /launch/app/node_modules/express/node_modules/escape-html
[email protected] /launch/app/node_modules/express/node_modules/etag
[email protected] /launch/app/node_modules/express/node_modules/finalhandler
[email protected] /launch/app/node_modules/express/node_modules/parseurl
[email protected] /launch/app/node_modules/express/node_modules/fresh
[email protected] /launch/app/node_modules/express/node_modules/merge-descriptors
[email protected] /launch/app/node_modules/express/node_modules/methods
[email protected] /launch/app/node_modules/express/node_modules/path-to-regexp
[email protected] /launch/app/node_modules/express/node_modules/proxy-addr
[email protected] /launch/app/node_modules/express/node_modules/forwarded
[email protected] /launch/app/node_modules/express/node_modules/ipaddr.js
[email protected] /launch/app/node_modules/express/node_modules/range-parser
[email protected] /launch/app/node_modules/express/node_modules/safe-buffer
[email protected] /launch/app/node_modules/express/node_modules/send
[email protected] /launch/app/node_modules/express/node_modules/destroy
[email protected] /launch/app/node_modules/express/node_modules/mime
[email protected] /launch/app/node_modules/express/node_modules/serve-static
[email protected] /launch/app/node_modules/express/node_modules/utils-merge
[email protected] /launch/app/node_modules/express/node_modules/vary
npm notice created a lockfile as package-lock.json. You should commit this file.
npm WARN [email protected] No description
npm WARN [email protected] No repository field.

up to date in 0.347s
*** EXPORTING:
Error: failed to get image for packs/v3:run
Usage:
  pack build [IMAGE NAME] [flags]

Flags:
      --detect-image string   detect image (default "packs/v3:detect")
  -h, --help                  help for build
  -p, --path string           path to app dir (default "/Users/dabou/Code/go-workspace/src/github.com/buildpack/pack")
  -r, --publish               publish to registry

docker pull packs/v3:run                                          
Trying to pull repository docker.io/packs/v3 ... 
run: Pulling from docker.io/packs/v3
c64513b74145: Already exists 
01b8b12bad90: Already exists 
c5d85cf7a05f: Already exists 
b6b268720157: Already exists 
e12192999ff1: Already exists 
9ec0afc3dd8c: Already exists 
8a8b744b79d4: Already exists 
c8c61c40292b: Already exists 
bfbfbd08c7bd: Already exists 
3c1241c68295: Pull complete 
Digest: sha256:793a13d1c313063dcc77713ec63338fa790588fc4b1c0a3dfb4b751bda18343d
Status: Downloaded newer image for docker.io/packs/v3:run

 ./pack build myorg/myapp -p acceptance/fixtures/node_app --publish
*** DETECTING:
2018/08/23 07:44:28 Group: Sample Node.js Buildpack: pass
*** ANALYZING: Reading information from previous image for possible re-use
*** BUILDING:
[email protected] /launch/app/node_modules/express
[email protected] /launch/app/node_modules/express/node_modules/accepts
[email protected] /launch/app/node_modules/express/node_modules/mime-types
[email protected] /launch/app/node_modules/express/node_modules/mime-db
[email protected] /launch/app/node_modules/express/node_modules/negotiator
[email protected] /launch/app/node_modules/express/node_modules/array-flatten
[email protected] /launch/app/node_modules/express/node_modules/body-parser
[email protected] /launch/app/node_modules/express/node_modules/bytes
[email protected] /launch/app/node_modules/express/node_modules/content-type
[email protected] /launch/app/node_modules/express/node_modules/debug
[email protected] /launch/app/node_modules/express/node_modules/ms
[email protected] /launch/app/node_modules/express/node_modules/depd
[email protected] /launch/app/node_modules/express/node_modules/http-errors
[email protected] /launch/app/node_modules/express/node_modules/inherits
[email protected] /launch/app/node_modules/express/node_modules/setprototypeof
[email protected] /launch/app/node_modules/express/node_modules/statuses
[email protected] /launch/app/node_modules/express/node_modules/iconv-lite
[email protected] /launch/app/node_modules/express/node_modules/on-finished
[email protected] /launch/app/node_modules/express/node_modules/ee-first
[email protected] /launch/app/node_modules/express/node_modules/qs
[email protected] /launch/app/node_modules/express/node_modules/raw-body
[email protected] /launch/app/node_modules/express/node_modules/raw-body/node_modules/http-errors
[email protected] /launch/app/node_modules/express/node_modules/raw-body/node_modules/depd
[email protected] /launch/app/node_modules/express/node_modules/raw-body/node_modules/setprototypeof
[email protected] /launch/app/node_modules/express/node_modules/unpipe
[email protected] /launch/app/node_modules/express/node_modules/type-is
[email protected] /launch/app/node_modules/express/node_modules/media-typer
[email protected] /launch/app/node_modules/express/node_modules/content-disposition
[email protected] /launch/app/node_modules/express/node_modules/cookie
[email protected] /launch/app/node_modules/express/node_modules/cookie-signature
[email protected] /launch/app/node_modules/express/node_modules/encodeurl
[email protected] /launch/app/node_modules/express/node_modules/escape-html
[email protected] /launch/app/node_modules/express/node_modules/etag
[email protected] /launch/app/node_modules/express/node_modules/finalhandler
[email protected] /launch/app/node_modules/express/node_modules/parseurl
[email protected] /launch/app/node_modules/express/node_modules/fresh
[email protected] /launch/app/node_modules/express/node_modules/merge-descriptors
[email protected] /launch/app/node_modules/express/node_modules/methods
[email protected] /launch/app/node_modules/express/node_modules/path-to-regexp
[email protected] /launch/app/node_modules/express/node_modules/proxy-addr
[email protected] /launch/app/node_modules/express/node_modules/forwarded
[email protected] /launch/app/node_modules/express/node_modules/ipaddr.js
[email protected] /launch/app/node_modules/express/node_modules/range-parser
[email protected] /launch/app/node_modules/express/node_modules/safe-buffer
[email protected] /launch/app/node_modules/express/node_modules/send
[email protected] /launch/app/node_modules/express/node_modules/destroy
[email protected] /launch/app/node_modules/express/node_modules/mime
[email protected] /launch/app/node_modules/express/node_modules/serve-static
[email protected] /launch/app/node_modules/express/node_modules/utils-merge
[email protected] /launch/app/node_modules/express/node_modules/vary
npm notice created a lockfile as package-lock.json. You should commit this file.
npm WARN [email protected] No description
npm WARN [email protected] No repository field.

up to date in 0.296s
*** EXPORTING:
Error: failed to get image for packs/v3:run
Usage:
  pack build [IMAGE NAME] [flags]

Flags:
      --detect-image string   detect image (default "packs/v3:detect")
  -h, --help                  help for build
  -p, --path string           path to app dir (default "/Users/dabou/Code/go-workspace/src/github.com/buildpack/pack")
  -r, --publish               publish to registry

Is it a bug or a step not described within the doc ?

https://storage.cloud.google.com/pack-cli/pack-darwin
https://storage.cloud.google.com/pack-cli/pack-linux

My buildpack scripts keep having to refer to their own id and version. E.g. to construct a launch.toml I need to refer to a launch layer:

cat > $launch/launch.toml <<EOF
[[processes]]
type = "web"
command = "/workspace/${BUILD_PACK_ID}/native/demo"
EOF

or to get a reference to a cache entry I need /buildpacks/${BUILD_PACK_ID}/${BUILD_PACK_VERSION}. Those env vars are not available so I have to hard code their values, even though the builder knows their values from builder.toml.

Maybe this is all part of some plan, but isn't it kind of dumb to have to enumerate all the stacks that a buildpack can run on in buildpack.toml? What if there's a new stack which is epsilon different from bionic? Shouldn't my buildpack be able to run on that?

As a custom buildpack author
I want to be able to use custom build pack images with the pack cli
So that they can be used by other developers

Scenario : Use custom detect image

GIVEN I have my own custom buildpack detect image
WHEN I specify this image during pack build --detect-image <image-name>
THEN I will be able to use the custom detection image to detect and build my source code

Note

• stack flag will go away
• detect image controls ability to detect and the ability to provide custom buildpacks
• ensure repository for order.toml group is used for both build and export (if work is required to suppor this, we will need to break out into another story)

I get that it is an abstraction, and abstractions have some value, but this one feels too opaque to me. I can copy-paste stack IDs around in my buildpack.tomls but I don't really understand what they are. I gather, by changing them, that they kind of represent a base image. There's probably more to it than that, or else why not just call it "base image"? It might be good to know what the image is though, so I can have a look inside it and figure out if my buildpack is ever going to run on it.

Can you please add some top-level documentation on building this project?

GIVEN I have custom v3 buildpacks on my local machine
WHEN I run pack create-builder <builder image name> -b /path/to/builder.toml (required) --publish(optional)
AND the order.toml file includes the list of custom buildpacks with the path to their source code
THEN a custom build image will be built with the default stack
AND include the custom buildpacks defined in the order.toml
AND the image sha will be returned to the user in the following format :

Successfully created builder image: <builder-image name:tag>

Tip: Run "pack build <image name> --builder <builder image> --path <app source code>" to use this builder

Notes

• stack defaults to io.buildpacks.stacks.bionic.
• construct /buildpack directory automatically in the builder
• if --publish is included - then publish image to corresponding registry defined in the image name
• Example builder.toml - every field must have a source

[[buildpacks]]
id = "com.example.buildpacks.nodejs"
uri = "file:///local/nodejs-buildpack.tgz"
[[buildpacks]]
id = "com.example.buildpacks.ruby"
uri = ""file:///local/ruby-buildpack.tgz""

[[groups]]
buildpacks = [
  { id = "com.example.buildpacks.nodejs", optional = true, version="exact version"},
  { id = "com.example.buildpacks.ruby", version="exact version"}
]

pack build

As a developer I want to use the pack buildcommand to create an image so that I can build my app using buildpacks, and run it similarly to how it will run in production

Acceptance Criteria

Given I have installed docker
Given Source code in a directory <app-dir>
When I run pack build --dir <app-dir> --name <repo-name>:<tag-name (optional)>
Then The pack cli builds an image from the source code in <app-dir> with the v3 buildpack lifecycle and puts it in <repo-name> in the local Docker daemon
Then I can run docker run ` and see my app running

Assumptions

1. For this first story we assume the image is fetched from and written to the docker daemon
2. We can skip restorer and cacher in this first iteration
3. We can assume the correct stack is packs/v3 on dockerhub

I believe the temp dir created here is not actually removed, because it is not empty by the time defer runs.

WHEN I run pack delete-stack my.custom.stack.id
THEN the stack associated with that ID in the config.toml will be deleted
AND the following message will be displayed to the user
my.custom.stack.id has been successfully deleted

Notes

• If the stack ID passed in does not exist, then return the following message <stack id> does not exist. Please pass in a valid stack ID.
• If stack ID passed in is set as the default stack, do not delete the stack and return the following message <stack id> cannot be deleted when it is the default stack. You can change your default stack by running "pack set-default-stack".

This used to work. Not sure what changed, but I don't think it was anything I did.

$ pack build dsyer/app --builder dsyer/builder --no-pull
$ docker run -p 8080:8080 dsyer/app
docker: Error response from daemon: No command specified.
See 'docker run --help'.
$ docker inspect dsyer/app
...
            "Entrypoint": null,
...

The image is fine apart from the entry point, so I can run it if I provide on manually, i.e. docker run dsyer/app /lifecycle/launcher web.

When creating a builder via pack create-builder -b builder.toml, the builder.toml currently has to reference each involved buildpack with a path that needs to exist on the local filesystem (file://). This is cumbersome and hinders the ability to distribute the sources for a builder (you don't want to put each buildpack binary in source control)

WHEN I run pack add-stack my.custom.stack --run-image my-org/run --build-image my-org/build
THEN a stack will be added to the config.toml file in the following format
AND return the following message to the user "<stack ID> successfully added."

[[stacks]]
id = “my.custom.stack”
run-images = ["my-org/run" ]
build-images = ["my-org/build"]

Note

• Can accept multiple run and build images by specifying -r and-b multiple times
• -r is shorthand for --run-image
• -b is shorthand for --build-image
• If stack ID already exists - return a message stating "<stack ID> already exists, please run update-stack to make updates" and then fail

GIVEN I have a custom builder image
WHEN I run pack build <app image> --builder <builder image> --path <path to source code>
THEN the application image will be built using the images defined in the builder image

Notes

• If no builder image is defined - default packs/samples image from stack list will be used
• Detect image flag / functionality should be removed
• --publish flag should function as expected

pack build produces a lot of meaningful output. When invoking pack.Build() via the API instead of the CLI, it's useful to be able to collect this output and redirect/transform it. This is commonly done by the caller passing a logger or an io.Writer to use.