2. ✅ Added CNB_EXEC_ENV to the extender phase - The environment variable is now included in the extender inputs table.
3. ✅ Clarified buildpack/group skipping behavior - Added clear documentation in the detector section explaining how the lifecycle handles buildpacks and groups when execution
environments don't match.
4. ✅ Updated launch metadata recording - Modified the metadata.toml documentation to specify that exec-env should use ["*"] for processes that apply to all environments, with clear
guidance that omitted values default to ["*"].
Signed-off-by: Juan Bustamante <bustamantejj@gmail.com>
- Added formal specification text for exec-env in processes
- Added formal specification text for exec-env in layer metadata
Signed-off-by: Juan Bustamante <bustamantejj@gmail.com>
- Added new [[buildpack.exec-env]] section with name field
- Added documentation explaining that [[buildpack.exec-env]] is optional and lists supported execution environments
- Removed exec-env documentation from the Targets section
- Added exec-env field to [[order.group]] TOML example
- Added documentation explaining that buildpack references in a group MAY contain an exec-env array
Signed-off-by: Juan Bustamante <bustamantejj@gmail.com>
The text `<build-config>` is not defined in this document as the `buildpack.md` is aimed at buildpack authors. The `CNB_PLATFORM_DIR` is referenced at the top of the document and is generally more recognizable by a buildpack author.
The platform docs specify this in their own document:
> Operator-provided environment variables MUST be supplied by the platform as files in the `<build-config>/env/` directory.
Signed-off-by: Schneems <richard.schneeman+foo@gmail.com>
The problem is described in https://github.com/buildpacks/docs/pull/841. While looking at the docs I was trying to determine if the platform env dir is provided when using `clear-env = true` and reading this paragraph in isolation it appeared that it was not.
It's now clear that "in the environment of `/bin/detect` or `/bin/build`" is referring to the specific "the environment" of the process and not the general "the environment" of the buildpack. However at the time, I somehow managed to mis-read this.
The sentence I'm adding, is redundant based on the paragraph above it, but I feel this helps clarify what's going on to a casual reader.
Signed-off-by: Schneems <richard.schneeman+foo@gmail.com>
1. Added clarification about platform behavior when the execution environment differs between builds
2. Added a note prohibiting the / character in execution environment values as it's reserved
Signed-off-by: Juan Bustamante <bustamantejj@gmail.com>
- Added formal specification text for exec-env in processes
- Added formal specification text for exec-env in layer metadata
Signed-off-by: Juan Bustamante <bustamantejj@gmail.com>
- Added new [[buildpack.exec-env]] section with name field
- Added documentation explaining that [[buildpack.exec-env]] is optional and lists supported execution environments
- Removed exec-env documentation from the Targets section
- Added exec-env field to [[order.group]] TOML example
- Added documentation explaining that buildpack references in a group MAY contain an exec-env array
Signed-off-by: Juan Bustamante <bustamantejj@gmail.com>
The text `<build-config>` is not defined in this document as the `buildpack.md` is aimed at buildpack authors. The `CNB_PLATFORM_DIR` is referenced at the top of the document and is generally more recognizable by a buildpack author.
The platform docs specify this in their own document:
> Operator-provided environment variables MUST be supplied by the platform as files in the `<build-config>/env/` directory.
Signed-off-by: Schneems <richard.schneeman+foo@gmail.com>
The problem is described in https://github.com/buildpacks/docs/pull/841. While looking at the docs I was trying to determine if the platform env dir is provided when using `clear-env = true` and reading this paragraph in isolation it appeared that it was not.
It's now clear that "in the environment of `/bin/detect` or `/bin/build`" is referring to the specific "the environment" of the process and not the general "the environment" of the buildpack. However at the time, I somehow managed to mis-read this.
The sentence I'm adding, is redundant based on the paragraph above it, but I feel this helps clarify what's going on to a casual reader.
Signed-off-by: Schneems <richard.schneeman+foo@gmail.com>
2. ✅ Added CNB_EXEC_ENV to the extender phase - The environment variable is now included in the extender inputs table.
3. ✅ Clarified buildpack/group skipping behavior - Added clear documentation in the detector section explaining how the lifecycle handles buildpacks and groups when execution
environments don't match.
4. ✅ Updated launch metadata recording - Modified the metadata.toml documentation to specify that exec-env should use ["*"] for processes that apply to all environments, with clear
guidance that omitted values default to ["*"].
Signed-off-by: Juan Bustamante <bustamantejj@gmail.com>
2. ✅ Added CNB_EXEC_ENV to the extender phase
3. ✅ Clarified buildpack/group skipping behavior for environment mismatches in the detector section
4. ✅ Updated metadata recording to include exec-env field with proper documentation about using ["*"] for all environments
The changes ensure that:
- The execution environment is properly propagated through all relevant lifecycle phases
- The behavior for environment mismatches is clearly defined
- Process metadata properly records execution environment restrictions using ["*"] for universal processes
Signed-off-by: Juan Bustamante <bustamantejj@gmail.com>
1. Added clarification about platform behavior when the execution environment differs between builds
2. Added a note prohibiting the / character in execution environment values as it's reserved
Signed-off-by: Juan Bustamante <bustamantejj@gmail.com>
Terence Lee