Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CNB_TARGET_DISTRO_NAME and CNB_TARGET_DISTRO_VERSION not set correctly in buildpack env #1324

Closed
edmorley opened this issue Mar 27, 2024 · 3 comments · Fixed by #1325
Closed
Labels
status/ready type/bug Something isn't working

Comments

@edmorley
Copy link
Contributor

edmorley commented Mar 27, 2024

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.

@edmorley edmorley added status/triage type/bug Something isn't working labels Mar 27, 2024
@natalieparellano
Copy link
Member

Thanks @edmorley - this is indeed a bug. It looks like we set the label constant incorrectly here:

// OSDistroNameLabel is the label containing the OS distribution name.
OSDistroNameLabel = "io.buildpacks.distro.name"
// OSDistroVersionLabel is the label containing the OS distribution version.
OSDistroVersionLabel = "io.buildpacks.distro.version"

@natalieparellano
Copy link
Member

We will probably want to backport this fix for this to 0.17.x for the reasons described in #1309 (comment)

@edmorley
Copy link
Contributor Author

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 :-)).

edmorley added a commit to edmorley/lifecycle that referenced this issue Mar 27, 2024
The spec and docs say that the run image distro and version should be
specified via the Docker image labels `io.buildpacks.base.distro.name`
and `io.buildpacks.base.distro.version`.

See:
https://github.com/buildpacks/spec/blob/buildpack/v0.10/platform.md#target-data

However, until now the lifecycle implementation was checking for
label names that were missing the `.base` substring from the name.

This causes distro name/version `buildpack.toml` target detection
to fail, as well as the env vars `CNB_TARGET_DISTRO_NAME` and
`CNB_TARGET_DISTRO_VERSION` not to be set correctly in the
buildpack environment.

Fixes buildpacks#1324.
edmorley added a commit to edmorley/lifecycle that referenced this issue Mar 27, 2024
The spec and docs say that the run image distro and version should be
specified via the Docker image labels `io.buildpacks.base.distro.name`
and `io.buildpacks.base.distro.version`.

See:
https://github.com/buildpacks/spec/blob/buildpack/v0.10/platform.md#target-data

However, until now the lifecycle implementation was checking for
label names that were missing the `.base` substring from the name.

This causes distro name/version `buildpack.toml` target detection
to fail, as well as the env vars `CNB_TARGET_DISTRO_NAME` and
`CNB_TARGET_DISTRO_VERSION` not to be set correctly in the
buildpack environment.

Fixes buildpacks#1324.

Signed-off-by: Ed Morley <501702+edmorley@users.noreply.github.com>
natalieparellano pushed a commit that referenced this issue Mar 28, 2024
The spec and docs say that the run image distro and version should be
specified via the Docker image labels `io.buildpacks.base.distro.name`
and `io.buildpacks.base.distro.version`.

See:
https://github.com/buildpacks/spec/blob/buildpack/v0.10/platform.md#target-data

However, until now the lifecycle implementation was checking for
label names that were missing the `.base` substring from the name.

This causes distro name/version `buildpack.toml` target detection
to fail, as well as the env vars `CNB_TARGET_DISTRO_NAME` and
`CNB_TARGET_DISTRO_VERSION` not to be set correctly in the
buildpack environment.

Fixes #1324.

Signed-off-by: Ed Morley <501702+edmorley@users.noreply.github.com>
natalieparellano pushed a commit that referenced this issue Mar 28, 2024
The spec and docs say that the run image distro and version should be
specified via the Docker image labels `io.buildpacks.base.distro.name`
and `io.buildpacks.base.distro.version`.

See:
https://github.com/buildpacks/spec/blob/buildpack/v0.10/platform.md#target-data

However, until now the lifecycle implementation was checking for
label names that were missing the `.base` substring from the name.

This causes distro name/version `buildpack.toml` target detection
to fail, as well as the env vars `CNB_TARGET_DISTRO_NAME` and
`CNB_TARGET_DISTRO_VERSION` not to be set correctly in the
buildpack environment.

Fixes #1324.

Signed-off-by: Ed Morley <501702+edmorley@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status/ready type/bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants