`CNB_TARGET_DISTRO_NAME` and `CNB_TARGET_DISTRO_VERSION` not set correctly in buildpack env

[edmorley]

Summary

The Buildpack API 0.10 spec says:

The following environment variables MUST be set by the lifecycle during the detect and build phases to describe the target runtime image, if inputs are provided.

... CNB_TARGET_DISTRO_NAME Target OS distribution name (optional) CNB_TARGET_DISTRO_VERSION Target OS distribution version (optional)

(https://github.com/buildpacks/spec/blob/buildpack/v0.10/buildpack.md#targets)

However, these env vars aren't being set for us, even though the relevant io.buildpacks.base.distro.* labels are set on the run (and build) images per: https://github.com/buildpacks/spec/blob/buildpack/v0.10/platform.md#target-data

---

Reproduction

Steps

1. pack buildpack new testcase-target-env-vars --api 0.10 --targets "linux/amd64"
2. sed -i 's/exit 0/printenv | grep CNB_TARGET | sort/' testcase-target-env-vars/bin/build
3. pack build --builder heroku/builder:22 --buildpack testcase-target-env-vars/ --path testcase-target-env-vars/ testapp --verbose
4. docker inspect heroku/heroku:22-cnb | jq '.[0].Config.Labels'

Current behavior

The CNB_TARGET_DISTRO_NAME and CNB_TARGET_DISTRO_VERSION env vars are not set correctly in the buildpack env:

$ pack build --builder heroku/builder:22 --buildpack testcase-target-env-vars/ --path testcase-target-env-vars/ testapp --verbose
...
Container Settings:
  Args: /cnb/lifecycle/creator -daemon -launch-cache /launch-cache -log-level debug -app /workspace -cache-dir /cache -run-image heroku/heroku:22-cnb testapp
  System Envs: CNB_PLATFORM_API=0.12
  Image: pack.local/builder/6e74726e78756f6c6b64:latest
  User: root
  Labels: map[author:pack]
...
===> ANALYZING
...
Run image info in analyzed metadata is: 
{"Reference":"3cba905f33fc964c9621c6938668fbc9184bdc4b7846b3578b5fef967600e2c2","Image":"heroku/heroku:22-cnb","Extend":false,"target":{"os":"linux","arch":"amd64"}}
...
===> BUILDING
...
CNB_TARGET_ARCH=amd64
CNB_TARGET_ARCH_VARIANT=
CNB_TARGET_DISTRO_NAME=
CNB_TARGET_DISTRO_VERSION=
CNB_TARGET_OS=linux
...

Note: The analyser phase says "target":{"os":"linux","arch":"amd64"} when I presume there should be keys in there for distro?

Checking our run image, it does have the required io.buildpacks.base.distro.* labels set:

$ docker inspect heroku/heroku:22-cnb | jq '.[0].Config.Labels'
{
  "io.buildpacks.base.distro.name": "ubuntu",
  "io.buildpacks.base.distro.version": "22.04",
  "io.buildpacks.base.homepage": "https://github.com/heroku/base-images",
  "io.buildpacks.base.maintainer": "Heroku",
  "io.buildpacks.stack.id": "heroku-22",
  "org.opencontainers.image.ref.name": "ubuntu",
  "org.opencontainers.image.version": "22.04"
}

Expected behavior

For the CNB_TARGET_DISTRO_* env vars to be set, eg:

CNB_TARGET_DISTRO_NAME=ubuntu
CNB_TARGET_DISTRO_VERSION=22.04

---

Context

lifecycle version

0.19.0

platform version(s)

$ pack report
Pack:
  Version:  0.33.2+git-f2cffc4.build-5562
  OS/Arch:  darwin/arm64

The build is using Platform API 0.12 and Buildpack API 0.10.

[natalieparellano]

Thanks @edmorley - this is indeed a bug. It looks like we set the label constant incorrectly here: https://github.com/buildpacks/lifecycle/blob/435d226f1ed54b0bec806716ba79e14a2a093736/platform/run_image.go#L19-L22

[natalieparellano]

We will probably want to backport this fix for this to 0.17.x for the reasons described in https://github.com/buildpacks/lifecycle/pull/1309#issuecomment-1988929012

[edmorley]

It looks like we set the label constant incorrectly here:

Ah good spot!

I was going to ask how we might test the fix, but it seems there are tests, just that they also test the wrong label - so we can update those to get coverage: https://github.com/search?q=repo%3Abuildpacks%2Flifecycle+%22io.buildpacks.distro%22+path%3A%2F%5Ephase%5C%2F%2F&type=code

I've also GitHub code searched to check nothing else (spec, docs, rfcs etc) is using the wrong label - and the rest looks fine.

I can open a PR for this in a couple of hours after I've eaten (unless someone else beats me to it, which is fine too :-)).