Extender-lib PoC buildpack/extension environment propagation not functioning as expected

[BarDweller]

Summary

This applies only to the extender-lib poc branch

Builder images can set ENV vars that are available to their contained buildpacks, notably today, this includes the CNB_STACK_ID, and CNB_USER_ID and CNB_GROUP_ID env vars.

The PoC currently does not make these env vars available to buildpacks executing following build image extension.

---

Reproduction

Steps

1. Create a buildpack that echoes CNB_STACK_ID during the build phase
2. Run the buildpack as part of the PoC
3. Notice the CNB_STACK_ID is empty

Current behavior

It looks like CNB_STACK_ID is ok when accessed from the detect phase, and the extension build phase. But the subsequent execution of the buildpacks within the extended image is then missing that env.

Expected

CNB_STACK_ID (and any other env vars defined by the builder image, and possibly by extensions to the builder image) should be available to the buildpacks when they are executed within the context of the extended builder image.

---

Context

lifecycle version

0.8

platform version(s)

n/a

anything else?

This appears to be because the extender image is separate from the builder/run images, within the PoC the extender image is built within the test-extender.sh script. The extender image is then used to create the container the extender binary runs within, and thus when the extender binary executes, it's os environment is lacking CNB_STACK_ID (and any other env vars defined by the builder image, and any extensions to the builder image).

The extender binary performs the extension, during which the Dockerfiles created by the extension build phase are applied. It appears (should be confirmed) that the Dockerfiles do have access to the CNB_STACK_ID during their execution, possibly because they are executing within the context of the builder image being extended, rather than the extender image which launched the extender binary.

The extender binary then proceeds to invoke the builder binary within the extended image, but is doing so using the environment context of the extender binary, which was created by the extender image. Thus when the builder runs to execute the buildpacks in the PoC, it is missing the environment it would expect.

I wonder what would happen if the builder binary wasn't invoked by the extender binary, but instead was invoked by a RUN command applied via the extender phase (eg, one final Dockerfile that would execute the builder).. I suspect this would get the right env, but would probably struggle with mounted volumes and other args usually used for docker run.. maybe a final Dockerfile could be used to execute the 'env' command to retrieve the environment then used to drive the builder command..

[natalieparellano]

Great catch @BarDweller ! Could you check https://github.com/buildpacks/lifecycle/pull/845 ? I believe that fixes it.

[BarDweller]

Confimed as Fixed =)