From d789f612a5a17edeff9b6c90e377821e8216be7c Mon Sep 17 00:00:00 2001 From: Terence Lee Date: Tue, 7 Jan 2025 10:14:48 -0600 Subject: [PATCH] add label Signed-off-by: Terence Lee --- text/0000-execution-environments.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/text/0000-execution-environments.md b/text/0000-execution-environments.md index 837c0243d..564ced647 100644 --- a/text/0000-execution-environments.md +++ b/text/0000-execution-environments.md @@ -76,10 +76,10 @@ In order to support additional execution environments an `exec-env` key will be An app developer may have execution environment configuration like only using a metrics agent in production or headless user agent needs in test. In order to facilitate these needs, the project descriptor will be extended by adding `exec-env` to the following tables: -`[[io.buildpacks.group]]` -`[[io.buildpacks.pre.group]]` -`[[io.buildpacks.post.group.env]]` -`[[io.buildpacks.build.env]]` +* `[[io.buildpacks.group]]` +* `[[io.buildpacks.pre.group]]` +* `[[io.buildpacks.post.group.env]]` +* `[[io.buildpacks.build.env]]` An example would look like this: @@ -160,6 +160,8 @@ This would let a buildpack author do different things based on the execution env It will be up to the platform to set the environment variable `CNB_EXEC_ENV`. If this value is set, `lifecycle` MUST NOT override this value. If the value is not set, `lifecycle` will set it to `production`. +During the export phase, `lifecycle` will set the `io.buildpacks.exec-env` label with the value from the `CNB_EXEC_ENV` environment variable. This will make it easier for anyone examining the OCI image to determine the execution environment. + # Migration [migration]: #migration @@ -214,6 +216,7 @@ The original Cloud Native Buildpacks spec included a Develop API, but it was nev - What changes are needed in the buildpack registry? - Does `build.env` need to support execution environments in `builder.toml`? - Should the reserved exec env strings be namespaced? +- Instead of creating a new label, should we stash it into a JSON label? # Spec. Changes (OPTIONAL) [spec-changes]: #spec-changes