CNB shim defaults to Buildpack API 0.4 which is deprecated

[edmorley]

As of lifecycle 0.16+, any Buildpack API version lower than 0.7 is deprecated. Currently cnb-shim defaults to Buildpack API 0.4, which means warnings like the following can be seen in the pack build output when using heroku/builder-classic:22 - for example:

===> DETECTING
Warning: Buildpack 'heroku/[email protected]' requests deprecated API '0.4'
Warning: Buildpack 'heroku/[email protected]' requests deprecated API '0.4'
Warning: Buildpack 'heroku/[email protected]' requests deprecated API '0.4'
Warning: Buildpack 'heroku/[email protected]' requests deprecated API '0.4'
Warning: Buildpack 'heroku/[email protected]' requests deprecated API '0.4'
Warning: Buildpack 'heroku/[email protected]' requests deprecated API '0.4'
Warning: Buildpack 'heroku/[email protected]' requests deprecated API '0.4'
Warning: Buildpack 'heroku/[email protected]' requests deprecated API '0.4'
Warning: Buildpack 'heroku/[email protected]' requests deprecated API '0.4'

Whilst cnb-shim supports overriding the choice of default Buildpack API version via URL parameters (eg &api=0.8), this only updates the API version listed in the generated buildpack.toml, and doesn't actually make the rest of cnb-shim compatible with the newer API versions.

An initial attempt at updating to a newer default Buildpack API version occurred in #66, however that was then reverted in #68 due to #67.

As mentioned in #67 (comment) fixing #67 is non-trivial, since the libbuildpack Go library that cnb-shim uses doesn't support newer Buildpack API versions - and in fact libbuildpack has been sunset in favour of the libcnb Go library, so cnb-shim would need to migrate to a new library.

Lastly, cnb-shim currently doesn't have any concept of supporting multiple buildpack API versions within the wrapper bash scripts or the releaser Go binary. So if we change cnb-shim to be compatible with newer Buildpack API versions, we'll then break compatibility with users specifying an older API version - unless we add support for multiple API versions, or decide to only support a single API version (which may not be viable, given users of the web service have no way to control when the service is updated).

All of these means we may want/need to reconsider the design/maintainability of cnb-shim longer term as part of trying to solve this issue.

GUS-W-13062656.

[edmorley]

The upstream CNB project is going to be releasing lifecycle 0.18.0 shortly. This new version drops support for the deprecated platform and buildpack API versions:
https://github.com/buildpacks/lifecycle/pull/1218/files?short_path=b335630#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5

This means any buildpack API version less than 0.7 will no longer be supported (once we update the Heroku builder images to use the new lifecycle release) - making cnb-shim no longer supported, unless it's upgraded/fixed.

Whilst we can probably hold off updating lifecycle in our builder images for a little bit, at some point we're going to have no choice but to update (e.g. needing new buildpack API features or lifecycle fixes).

[edmorley]

lifecycle 0.18.0 (that drops support for the Buildpack API version currently used by cnb-shim) is now out:
https://github.com/buildpacks/lifecycle/releases/tag/v0.18.0

[edmorley]

Noting here for completeness: The main heroku/builder:* Heroku CNB builder images were upgraded to lifecycle 0.18.0 in November 2023 (in heroku/cnb-builder-images#431), since we couldn't wait any longer for cnb-shim to be modernised, so the cnb-shim hasn't worked with those builders since then. There has not been a single user notice or mention that cnb-shim no longer worked; it's usage is clearly non-existent outside of shimming the classic buildpacks in the older per-native-cnb builder images.

[chap]

@edmorley I wonder if we'll need to get this in ship shape with the launch of Fir and migration of customers to CNBs.

[edmorley]

@chap Hi!

We're leaning towards sunsetting this project since a shim based approach just isn't viable for a sizeable set of buildpacks:
#95

[edmorley]

(I've moved the longer answer above to #95 and pinned it, to improve visibility)