search

paketo-buildpacks / procfile

A buildpack for translating a Procfile into Process Types
Apache License 2.0
15 stars 11 forks source link

Support Buildpack API Version 0.9 #168

Open modulo11 opened 1 year ago

modulo11 commented 1 year ago

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 commented 1 year ago

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.

c0d1ngm0nk3y commented 1 month ago

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.