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

Support Buildpack API Version 0.9 #168

Open
modulo11 opened this issue Mar 14, 2023 · 2 comments
Open

Support Buildpack API Version 0.9 #168

modulo11 opened this issue Mar 14, 2023 · 2 comments
Labels
type:poll Request for feedback from the community

Comments

@modulo11
Copy link
Contributor

RFC-0093 pushes the decision if a shell is necessary from the lifecycle to the individual buildpacks.

Are there already ideas how to move the Procfile Buildpack to Buildpack API Version 0.9?

Possible Solution

  1. Push the decision for using a shell back to the user. This would be a breaking change. Example:
some-command: bash -c "run-something"
  1. Have some USE_SHELL environment variable which chooses the shell.
  2. Have a helper-like binary which auto-detects the shell to use
  3. Something else
@dmikusa
Copy link
Contributor

dmikusa commented Mar 14, 2023

Before we can support 0.9, we need libcnb to support it first. It does not at the moment. https://github.com/buildpacks/libcnb/blob/release-1.x/build.go#L95-L100. It might be easy to add though because I believe we've added support for RFC 93 already. It would just depend on what else is needed to be 0.9 compatible and then cutting a release.

I think my preference would be for solution 1.), given it's cleaner. We might be able to pair that with some detect logic to support both for a while though. We could have an env variable like BP_LEGACY_PROCFILE_ENABLED (defaults to false) and if that's true, it would wrap all of the Procfile commands in a shell (or if you wanted to get a little more complicated, the env variable could be a space-separated list of Procfile process names to be wrapped in a shell). We could then retain that backwards compatibility support for a while, maybe 6 months or a year, then remove it.

@dmikusa dmikusa added the type:poll Request for feedback from the community label Mar 14, 2023
@c0d1ngm0nk3y
Copy link
Contributor

The problem with that is that the lifecycle decides what shell to use for anything in the launch.toml with direct=false, but the lifecycle already implemented the solution quite some time ago, but only with BP_API 0.9. Like mentioned, we would need libcnb v2 for that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:poll Request for feedback from the community
Projects
None yet
Development

No branches or pull requests

3 participants