[Buildpack API] - Add Execution Enviroment definition #415
Conversation
Signed-off-by: Juan Bustamante <[email protected]>
Signed-off-by: Juan Bustamante <[email protected]>
| @@ -1021,7 +1044,8 @@ name = "<dependency name>" | |||
| cache = false | |||
|
|
|||
| [metadata] | |||
| # buildpack-specific data | |||
| exec-env = ["<execution environment>"] # Optional. If not specified, applies to all execution environments | |||
There was a problem hiding this comment.
Just to clarify on the platform side - if the previous image was built with a different value of exec-env do we do anything? Looking at the platform PR, it seems not. So do we expect buildpacks to inspect this value and re-create the layer if needed? If so we might want to call this out somewhere.
| ### Execution Environments | ||
|
|
||
| Execution environments define the context in which a buildpack-created application is intended to run. Standard values include: | ||
| - `production`: The default environment, optimized for running applications in production. |
There was a problem hiding this comment.
Is this in conflict with this part from the RFC? https://github.com/buildpacks/rfcs/pull/274/files#diff-5e1fecc151d09b271a5fd5407df8a4b069753c4b34b6687f5e1e7c2a29da7f33R71
Namely
An individual element can be any string with
*having special meaning. Similar to the "any stack RFC",*will apply to all execution environments.["*"]will be the default if not specified.
There was a problem hiding this comment.
Should we also add
In addition, the
/character is reserved in case we need to introduce namespacing in the future.
There was a problem hiding this comment.
If there's ambiguity around how this should work, I suggest we follow the same pattern as "targets", where missing means "any".
There was a problem hiding this comment.
yea, i think reserving the / now is a good idea.
i think we agreed in the rfc that default should be production, not *
…Specifically: 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 <[email protected]>
RFC-0134
- Added a dedicated "Execution Environments" section explaining the concept
- Defined standard values: production (default), test, and development
- Described how buildpacks should adapt behavior based on these environments
- Added CNB_EXEC_ENV to both the
detectandbuildphase inputs- Documented that when not set, it defaults to "production"
- Updated buildpack.toml to include exec-env in the targets section
- Updated launch.toml processes to include execution environment restrictions
- Updated Layer Content Metadata to support execution environment in metadata
- Added recommendations for how buildpacks should handle different environments
- Specified how layers and processes can be targeted to specific environments
- Clarified that buildpacks must assume "production" when no environment is specified
- Detailed how buildpacks can mark processes for specific execution environments
- Explained that layers can be environment-specific
- Provided guidance on optimizing build strategies per environment
These changes enable buildpacks to create different outputs depending on whether the application will be used in production, testing, or development contexts.