support for heroku-24

[jwhitcraft]

Hello,

Was just testing this out today and noticed this error when trying to setup a clusterbuilder with kapck:

 lastTransitionTime: 2024-10-11T21:51:22Z
    message: "validating buildpack heroku/procfile@3.1.2: stack heroku-24 is not
      supported"
    reason: ReconcileFailed
    status: "False"

[edmorley]

@jwhitcraft Hi! Thank you for filing an issue. This buildpack is compatible with Heroku-24 - and as far as I'm aware this buildpack defines all the correct compatibility metadata according to the Buildpack API spec (see buildpack.toml), so this might be a bug in lifecycle / kpack or a case of using an incompatible Platform API version?

What builder image are you using with the heroku/procfile CNB? heroku/builder:24 or a custom builder? If a Heroku builder, is the image up to date? If a custom builder, what version of lifecycle is specified in that builder's manifest?

For kpack, what kpack version is it, and do you know what Platform API version it is using?

[edmorley]

Oh and what OS/arch is being used? (If using a custom builder)

[jwhitcraft]

Hello!

No custom builder here yet, but we are building for x86_64 arch and linux, kpack is 0.15.0

Here is my ClusterStack

apiVersion: kpack.io/v1alpha2
kind: ClusterStack
metadata:
  name: heroku-24
spec:
  buildImage:
    image: public.ecr.aws/heroku/heroku:24-build
  id: heroku-24
  runImage:
    image: public.ecr.aws/heroku/heroku:24

Here is my ClusterStore

apiVersion: kpack.io/v1alpha2
kind: ClusterStore
metadata:
  name: heroku-24
spec:
  sources:
    - image: heroku/buildpack-nodejs:3.2.15
    - image: heroku/buildpack-procfile:3.1.2

And here is my ClusterBuilder

apiVersion: kpack.io/v1alpha2
kind: ClusterBuilder
metadata:
  name: heroku-24
spec:
  order:
    - group:
        - id: heroku/nodejs
        - id: heroku/procfile
  serviceAccountRef:
    name: kpack
    namespace: kpack
  stack:
    kind: ClusterStack
    name: heroku-24
  store:
    kind: ClusterStore
    name: heroku-24
  tag: my-cluster-build
  additionalLabels:
    io.buildpacks.base.distro.name: "ubuntu"
    io.buildpacks.base.distro.version: "24.04"

The one thing I did notice was that the buildpack.toml file for the Procfile doesn't have the stacks config in it.

[[stacks]]
id = "*"

https://github.com/heroku/buildpacks-nodejs/blob/main/buildpacks/nodejs-npm-engine/buildpack.toml#L14C1-L15C9

[jwhitcraft]

From the looks of it, even though stacks is deprecated, kpack is still checking for it, and failing when it doesn't exist:

https://github.com/buildpacks-community/kpack/blob/main/pkg/cnb/buildpack_validation.go#L12-L31

[edmorley]

Thank you for the extra details.

Here is my ClusterStack
...
And here is my ClusterBuilder

Those definitions are using the Heroku build and run images, but not Heroku's builder image. Heroku's builder images are published here:

• https://hub.docker.com/r/heroku/builder
• https://gallery.ecr.aws/heroku/builder

I'm not very familiar with kpack at all - looking now it seems it differs quite considerably from some of the other "platforms" (such as Pack CLI, or Heroku's internal CNB platform)

For example, it doesn't use https://github.com/buildpacks/lifecycle but ships its own, xref:

• Document why kpack uses a different lifecycle image buildpacks-community/kpack#1131
• Implement lifecycle CRD buildpacks-community/kpack#1628

And it also doesn't allow using a pre-built builder, and instead makes you use its custom types for the same?
https://github.com/buildpacks-community/kpack/blob/main/rfcs/0001-remove-builders.md
(This seems like a strange design choice, given people may want to use builders from other provides outside of those managed in a single kpack cluster)

From the looks of it, even though stacks is deprecated, kpack is still checking for it, and failing when it doesn't exist:

https://github.com/buildpacks-community/kpack/blob/main/pkg/cnb/buildpack_validation.go#L12-L31

Ah good spot. It looks like kpack needs updating to properly support Buildpack API 0.10 which deprecated stacks (making them optional in favour of targets):
https://github.com/buildpacks/spec/releases/tag/buildpack%2Fv0.10

It's probably worth filing an issue for this here:
https://github.com/buildpacks-community/kpack/issues

[jwhitcraft]

Thanks,

I filed the issue linked above, In the short term is there anyway that the [[stacks]] section could be added to unblock kpack users? All of your other Buildpacks have it defined,

I'd be more than happy to open an PR with it.

[edmorley]

Thank you for filing that issue.

Yeah I'm open to adding back [[stacks]] as a workaround - though it's more than just this repo that would need updating - only half the buildpacks have it set (the ones that weren't as proactive at removing the workaround once buildpacks/pack#2047 was fixed):

$ docker run --rm heroku/builder:24 bash -c 'find /cnb/buildpacks -name buildpack.toml | wc -l'
20
$ docker run --rm heroku/builder:24 bash -c 'grep -r "^\[\[stacks\]\]" /cnb/buildpacks | wc -l'
10

[jwhitcraft]

@edmorley i may have found a way around this, since we are on gitlab and don't have access to docker running in our clusters, we can run the lifecycle builder as part of job in gitlab

https://medium.com/@jonashackt/cloud-native-buildpacks-paketo-io-in-gitlab-ci-without-docker-pack-cli-486df71aa968,

going to try this out vs using kpack, will report back.

[jwhitcraft]

@edmorley

Great news this worked wonderfully and we are going to try and migrate this way of doing things over kpack, since there isn't much activity going on there right now.

Thanks again for all your help!

[edmorley]

Great! And no problem :-)

[edmorley]

Closing this out for now, since this was an upstream bug/limitation of kpack (it should reject Buildpack API 0.10 buildpacks if it doesn't fully support Buildpack API 0.10, plus would ideally support Buildpack API 0.10).