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

Asset Packages - Platform #228

Closed
wants to merge 1 commit into from
Closed

Asset Packages - Platform #228

wants to merge 1 commit into from

Conversation

nebhale
Copy link
Contributor

@nebhale nebhale commented Jun 2, 2021

This change updates the platform specification with asset package support.

[#201]

Signed-off-by: Ben Hale bhale@vmware.com

@nebhale nebhale requested a review from a team as a code owner June 2, 2021 00:11
@nebhale nebhale added this to the Platform 0.7 milestone Jun 2, 2021
This change updates the platform specification with asset package
support.

[#201]

Signed-off-by: Ben Hale <bhale@vmware.com>
@@ -832,6 +832,12 @@ The following variables SHOULD be set in the lifecycle execution environment and

The platform SHOULD NOT assume any other stack-provided environment variables are inherited by the buildpack.

##### Builder-Provided Variables
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible for a platform to provide this variable even if it doesn't use builders?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that calling out builders specifically here is inapproriate. Maybe Platform-Provided Variables? Although one could argue that stack-provided and user-provided variables are also platform-provided in a sense.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
##### Builder-Provided Variables
##### Platform-Provided Variables

I can't come up with something better, so I'm 👍 on that change.

@@ -832,6 +832,12 @@ The following variables SHOULD be set in the lifecycle execution environment and

The platform SHOULD NOT assume any other stack-provided environment variables are inherited by the buildpack.

##### Builder-Provided Variables
The following variables MAY be set in the lifecycle execution environment and SHALL be directly inherited by the buildpack without modification:
Copy link
Member

@natalieparellano natalieparellano Jun 9, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The following variables MAY be set in the lifecycle execution environment and SHALL be directly inherited by the buildpack without modification:
The following variables MAY be set in the lifecycle execution environment and SHALL be directly inherited by the buildpack without modification, if also supported by the buildpack API:

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@natalieparellano I think you are right that we need a caveat here but maybe we want something more generic? It seems weird to apply this specific carve-out to an entire table that could be extended to include more variables.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense! I modified my suggestion.

@ekcasey ekcasey marked this pull request as draft July 21, 2021 18:10
@hone
Copy link
Member

hone commented Jul 21, 2021

Since this is not making it into the next spec release, we're moving this into draft for now. More discussion to follow.

@ekcasey ekcasey removed this from the Platform 0.7 milestone Jul 21, 2021
@ekcasey ekcasey closed this Jan 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants