Arch specific dependencies

[joshwlewis]

When running pack buildpack package with a buildpack that has a docker dependency on a multi-arch image index like this:

[dependencies]
uri = "docker://heroku/buildpack-release-phase:1.0.3"

Pack defers the image resolution to docker. This works fine when packaging a buildpack for the host platform, but breaks when packaging for another architecture. The default docker image store (which pack uses) is not able to properly handle cross platform images. The error manifests like this:

ERROR: packaging dependencies (uri='docker://heroku/buildpack-release-phase:1.0.3',image=''): extracting from registry 'docker://heroku/buildpack-release-phase:1.0.3': extracting buildpacks from 'heroku/buildpack-release-phase:1.0.3': could not find label 'io.buildpacks.buildpackage.metadata'

This PR does a basic regex substitution to append the appropriate platform suffix, so the package.toml references the docker tag for the appropriate platform like this:

[dependencies]
uri = "docker://heroku/buildpack-release-phase:1.0.3_linux-arm64"

or

[dependencies]
uri = "docker://heroku/buildpack-release-phase:1.0.3_linux-amd64"

An example passing workflow that did not without this change: https://github.com/heroku/buildpacks-frontend-web/actions/runs/12381045454/job/34558845731

[mars]

Confirmed, this fixes the release publishing issue with the Front-end Web buildpacks.

[edmorley]

Thank you for digging into this!

I'm presuming the reason we haven't run into this before, is that all of our other composite buildpacks have libcnb: type dependencies rather than docker image dependencies in their package.toml?

Re Pack deferring platform resolution to Docker, does that mean there is a feature-gap in Pack's multi-arch support (eg it should propagate --platforms or similar but doesn't), or is it a case of us needing to migrate the automation here (which was written before Pack supported multi-arch properly) to the new Pack feature? If the former it would be good to file a bug/feature request upstream, and if the latter then I think we should create some GUS work items/epics for tracking refactoring multi-arch in FY26 (incl ideally pushing some of the handling down into libcnb-{cargo,package}.