Skip to content

Upgrade legacy builder image deprecation warnings to an error #474

@edmorley

Description

@edmorley

In June 2022, as part of the Heroku-22 release, we switched to a new Docker Hub repo for our builder images (from heroku/buildpacks:* to heroku/builder:*).

In addition to the change in repository name, the new heroku/builder:* namespaced builder images contain only Heroku's next-gen (fully native) Cloud Native Buildpacks, whereas the old heroku/buildpacks:* builder images contain a mixture of shimmed and native CNBs (since back when that builder image was created, we didn't yet have native CNBs for every supported language, so some had to be substituted using shimmed classic Heroku buildpacks).

For more details on the differences between the images, see:
https://github.com/heroku/cnb-builder-images/blob/main/README.md#available-images

To raise awareness of the deprecated nature of the old images, in October 2023:

IMO it's now time to upgrade this deprecation warnings to errors, since:

  • We're about to add many more image variants (due to multi-architecture + Ubuntu 24.04 support), so it would be helpful to reduce the number of supported builder images prior to that.
  • We're having to jump through additional hoops for these older images, like pinning the lifecycle version due to cnb-shim not being compatible with newer Buildpack API versions (see here).
  • It has been 21 months since we introduced the new heroku/builder:* repo and coming up to six months of us outputting loud deprecation warnings.
  • All of our builder images are still experimental/pre-GA/not used in production at Heroku (and marked as such in the README), so the amount of notice we've given is IMO already more than reasonable (once GA there will be more stability and longer deprecation periods).
  • We're preparing for a more official beta phase for our CNBs, so would like to reduce the chance of users trying out a deprecated image by mistake / to clean things up in general prior to then.

At least initially, we can make these errors skippable by setting an env var, similar to what we did for Heroku-18's EOL in #336.

I think we should do this within the next couple of weeks.

cc @heroku/languages

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions