RFC for build environment variables

[kappratiksha]

RFC for adding a new flag for build environment variables

[buildpack-bot]

Maintainers,

As you review this RFC please queue up issues to be created using the following commands:

/queue-issue <repo> "<title>" [labels]...
/unqueue-issue <uid>

Issues

(none)

[jjbustamante]

Hi @kappratiksha!

Thanks for contributing with this RFC!

My initial though is the suggested change is moving the creator to the platform field. As you correctly pointed out, pack offers a more user friendly way to set environment variables, but that is actually the kind of functionalities we are expecting from a platform implementation. In this case, the proposal seems to try to make the creator to look like a platform.

In the last working group meeting we discussed the problem with certain platforms, like google, having problems with mounting volumes with files to configure the lifecycle execution and exposing flags could be a better approach. l I think this RFC goes into that direction. With that in mind, I will suggest:

• Can we add more detail in the motivation section, describing for example a use case like: running the lifecycle creator in a kubernetes cluster, and trying to mount persistent volumes with a file containing environment variables is painfull because X or Y.

Also, based on the spec running the creator should be equivalent to running the phases individually, this means, the behavior added to the creator with the new --env flag should also be achievable with other phases, so I think the RFC should also detail how are we planning to do it.

[jabrown85]

Can you add details on order of precedence?

E.g. If a platform spits values into /platform/env today, say from a project.toml. The project.toml has FOO=bar. The platform decides that they always wanted to set FOO=baz via the new -env, what happens.