As an app developer, pack rebase automatically determines a run image using the available mirrors

ekcasey commented 5 years ago

Acceptance Criteria Given When I run pack build my-image Then I new version of the run image is available on all mirrors

Scenario 1 When I run pack rebase my-image (without --run-image) Then The run image under my-image is replaced with a run image from the appropriate source

Scenario 2 When I run pack rebase my-image --run-image custom/image Then The run image under my-image is replaced with custom/image

Notes

Mirror selection for the run image should use the same order as pack build. This means the run-image and run-image-mirrors from the builder used during pack build must be encoded in the generated OCI image on each pack build.
Update pack README to describe new model
buildpack/pack#90 covers updating --no-pull to work when only a local image is available
As with pack build --publish, pack rebase --publish should work when the run image is not available at the target registry. This means that if a suitable run image is not available on the registry, then select the canonical image.
Remove pack *-stack commands

Implementation Notes

Pack CLI should select run image from list of mirrors
pack create-builder should add a file (similar to order.toml) that also contains the run image mirror metadata (that is also available as a LABEL on the image). The file path should have a default value, but also be overridable using an arg or env var (like order.toml).
CNB_MIRRORS_PATH / -mirrors / /buildpacks/mirrors.toml

ekcasey commented 5 years ago

@sclevine

sclevine commented 5 years ago

Added acceptance criteria and notes.

djoyahoy commented 5 years ago

After a team discussion, we want to change this feature to have the following behavior:

Build

If the run-image used during build is not from the local config then include the run-image name as a label in the resulting app image.
If the run-image used during build is from the local config then do not include the run-image name as a label in the resulting app image.

Rebase

If the app image does have a run-image name in a label, use that for the rebase (Scenario 1).
If the app image does not have a run-image name in a label, require the user to specify a run-image with the --run-image flag (Scenario 2).

thisisnotashwin commented 5 years ago

Waiting on approval of https://github.com/buildpack/lifecycle/pull/90

pack changes on branch run_images_during_rebase to get merged after the above PR is merged

ekcasey commented 5 years ago

I think the desired end state we would like to get to is the following

`pack create-builder`

When the builder.toml has the following contents

[stack]
id = "com.example.stack"
build-image = "example/build"
run-image = "example/run"
run-image-mirrors = ["registry.example.com/exmaple/run", "other.example.com/other/run"]

Then the builder is created with a label io.buildpacks.builder.metadata with the following value

"{"runImage":{"image":"example/run","mirrors":["registry.example.com/exmaple/run", "other.example.com/other/run"]}"

And the following file is added to the builder image at path /buildpacks/mirrors.toml. And the following environment variable is set on the builder image CNB_MIRRORS_PATH=/buildpacks/mirrors.toml

`lifecycle/exporter`

Scenario 1 (default)

When exporter is called w/o the -runImage flag Then the exporter selects the right run image from the mirrors.toml file at CNB_MIRRORS_PATH And all the of the mirrors from the mirrors.toml file are add to the io.buildpacks.run-image.metadata label

"{"runImage":{"image":"example/run","mirrors":["registry.example.com/exmaple/run", "other.example.com/other/run"]}"

Scenario 2 (`-runImage`)

When exporter is called with the -runImage Then it uses the provided run-image as the base image for the exported app And the mirrors from mirrors.toml are added to a label as described above *The value passed to -runImage does not* end up in a label

Scenarios 3 & 4 (`-mirrors`)

When exporter is called with -mirrors=/some/path/mirrors.toml either with or without -runImage Then It behaves as described in scenarios 1 (without -runImage) & 2 (with -runImage) but the mirrors.toml is found at /some/path/mirrors.toml is used instead of the file found at CNB_MIRRORS_PATH

`pack rebase`

pack rebase selects the correct run image from the io.buildpacks.run-image.metadata label

Comments

I am comfortable with us doing some subset of this functionality now but I think the interim behavior the subset to conform to the same interface (lifecycle flag, label names, value names within the labels), requiring only additive changes in the future.

djoyahoy commented 5 years ago

With the above the changes, we should revert the change that added the label flag to the exporter.

sclevine commented 5 years ago

mirrors.toml

image = "string"
mirrors = ["string"]

ekcasey commented 5 years ago

We broke out the exporter selecting the run-image into buildpack/roadmap#58

We also made some last minute changes to the schema of metadata labels and files to reduce the total number of labels and the number of different names we use for the same concept

on the builder image:

we created a stack.toml file with the following schema

[run-image]
image = "string"
mirrors = ["string", "string"]

we added the stack image to the io.buildpacks.builder.metadata label

{"stack":{"runImage": {"image": "string", "mirrors": ["string", "string"]}}}

on the app image: we added the stack info to theio.buildpacks.lifecycle.metadata label

{"stack":{"runImage": {"image": "string", "mirrors": ["string", "string"]}}}

sclevine commented 5 years ago

Leaving this as unaccepted because I want to test more edge cases, but it looks good enough to release in v0.1.0.

buildpacks / roadmap