[Platform API] - Add Execution Environment definition #416
Conversation
Signed-off-by: Juan Bustamante <[email protected]>
Signed-off-by: Juan Bustamante <[email protected]>
| | `<app>` | `CNB_APP_DIR` | `/workspace` | Path to application directory | | ||
| | `<build-config>` | `CNB_BUILD_CONFIG_DIR` | `/cnb/build-config` | Path to build config directory | | ||
| | `<buildpacks>` | `CNB_BUILDPACKS_DIR` | `/cnb/buildpacks` | Path to buildpacks directory (see [Buildpacks Directory Layout](#buildpacks-directory-layout)) | | ||
| | `<exec-env>` | `CNB_EXEC_ENV` | `production` | Target execution environment. Standard values: "production", "test", "development". | |
There was a problem hiding this comment.
This all seems fine to me, but I'm looking at this comment from the RFC and I don't see that specified anywhere. Are we expecting the lifecycle to skip over buildpacks or groups that don't match the current environment?
There was a problem hiding this comment.
yes. the question is if we want to skip an entire group if one of the buildpack doesn't match the env. We need @hone to chime in there
There was a problem hiding this comment.
@jkutner @hone @natalieparellano here is a proposal
- When `CNB_EXEC_ENV` is set and differs from a previous build's execution environment:
- The lifecycle SHALL skip buildpacks that do not support the current execution environment
- If all buildpacks in a group are skipped due to execution environment mismatch, the lifecycle SHALL continue to the next group in the order
- The lifecycle SHOULD NOT restore layers from previous builds with different execution environments
Or do we want to skip the entire group?
|
This should be re-pointed at |
Signed-off-by: Juan Bustamante <[email protected]>
| | `<app>` | `CNB_APP_DIR` | `/workspace` | Path to application directory | | ||
| | `<build-config>` | `CNB_BUILD_CONFIG_DIR` | `/cnb/build-config` | Path to build config directory | | ||
| | `<buildpacks>` | `CNB_BUILDPACKS_DIR` | `/cnb/buildpacks` | Path to buildpacks directory (see [Buildpacks Directory Layout](#buildpacks-directory-layout)) | | ||
| | `<exec-env>` | `CNB_EXEC_ENV` | `production` | Target execution environment. Standard values: "production", "test", "development". | |
There was a problem hiding this comment.
We probably want CNB_EXEC_ENV in restorer as well. In order to do things like skip cache restore.
Extender also needs it I would think?
| args = ["<arguments>"] | ||
| direct = false | ||
| working-dir = "<working directory>" | ||
| exec-env = ["<execution environment>"] # Optional. If not specified, applies to all execution environments. The special value "*" indicates compatibility with all execution environments. If exec-env is ["*"] or not specified, the process is eligible for all execution environments. |
There was a problem hiding this comment.
Does this align with the following?
Documented that it defaults to "production" when not specified
I know the default input for the phases would be production when not set - I guess the buildpack could produce processes for production , test or omit the value in its launch.toml.
Is lifecycle going to record these launch toml values as * or omit? I would think *. I don't see a reason to omit values in this file/metadata.json
There was a problem hiding this comment.
Yeah, I agree that if not specified, we should record * in the launch toml. @hone ?
…able is now included in the restorer inputs table. 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 <[email protected]>
RFC-0134
- Added a definition for "execution environment" in the CNB Terminology section
- Defined standard values: production (default), test, and development
- Added CNB_EXEC_ENV to detector, builder, and launcher inputs
- Documented that it defaults to "production" when not specified
- Updated the launcher's process selection logic to respect execution environments
- Added rules to determine when a process is eligible for the current environment
- Specified that the launcher must fail if a requested process is not available for the current environment
- Updated metadata.toml to include exec-env in the process definitions
- Added execution environment to the io.buildpacks.build.metadata JSON format
- Added execution environment to the io.buildpacks.lifecycle.metadata JSON format
- Defined that a process is eligible for an execution environment if:
These changes enable platforms to specify which execution environment an application should be built for and run in, allowing buildpacks to provide different behaviors for different
environments (production, test, development).
Resolves #420