paketo-buildpacks/ca-certificates@3.8.2: stack io.buildpacks.stacks.jammy is not supported

[danail-branekov]

It seems that 3.8.2 does not support the jammy stack

Expected Behavior

Consider the following kpack builder configuration:

apiVersion: kpack.io/v1alpha2
kind: ClusterStore
metadata:
  name: cf-default-buildpacks
spec:
  sources:
  - image: gcr.io/paketo-buildpacks/java
  - image: gcr.io/paketo-buildpacks/nodejs
  - image: gcr.io/paketo-buildpacks/ruby
  - image: gcr.io/paketo-buildpacks/procfile
  - image: gcr.io/paketo-buildpacks/go

---
apiVersion: kpack.io/v1alpha2
kind: ClusterStack
metadata:
  name: cf-default-stack
spec:
  buildImage:
    image: paketobuildpacks/build-jammy-full
  id: io.buildpacks.stacks.jammy
  runImage:
    image: paketobuildpacks/run-jammy-full

---
apiVersion: kpack.io/v1alpha2
kind: ClusterBuilder
metadata:
  name: cf-kpack-cluster-builder
spec:
  order:
  - group:
    - id: paketo-buildpacks/java
  - group:
    - id: paketo-buildpacks/go
  - group:
    - id: paketo-buildpacks/nodejs
  - group:
    - id: paketo-buildpacks/ruby
  - group:
    - id: paketo-buildpacks/procfile
  serviceAccountRef:
    name: kpack-service-account
    namespace: cf
  stack:
    kind: ClusterStack
    name: cf-default-stack
  store:
    kind: ClusterStore
    name: cf-default-buildpacks
  tag: localregistry-docker-registry.default.svc.cluster.local:30050/kpack-builder

I would expect that the cluster builder becomes ready

Current Behavior

The cluster builder never becomes ready and the following error is reported to its status:

  - lastTransitionTime: "2024-07-01T11:05:46Z"
    message: 'validating buildpack paketo-buildpacks/ca-certificates@3.8.2: stack
      io.buildpacks.stacks.jammy is not supported'
    reason: ReconcileFailed
    status: "False"
    type: UpToDate

Possible Solution

I would speculate that the issue above is caused by removing the stacks tags in the buildpack.toml file in this commit: https://github.com/paketo-buildpacks/ca-certificates/commit/0166c6f7239e1a4a147f593bc3e43c567a32342f. Maybe bringing them back should fix it.

Steps to Reproduce

1. Install kpack on a k8s cluster
2. Apply the cluster stack/store/builder above, see the builder not becoming ready

Motivations

We would like our kpack builder to be able to use latest ca-certificates buildpack which does not seem to be the case anymore.

As a workaround we have pinned the java buildpack (that brings the ca-certificates buildpack) to the previous release (gcr.io/paketo-buildpacks/java:15.0.0)

[tuckeremulls]

Facing this same issue as well for one of our builders. Pinning java build pack to 15.0.0 as @danail-branekov has done as a temporary solution.

[sovereignstack]

Facing the same problem. Our CI pipeline is broken due to this. Pinning java build pack to 15.0.0 as a workaround. https://github.com/cloudfoundry/korifi/pull/3361

[jwhitcraft]

Just saw this on our pipline, had to backup dotnet-core to that v0.46

[dmikusa]

This was an accident, apologies.

We'll be adding the wildcard stack back into the metadata and cutting a new release shortly.

[pivotal-david-osullivan]

Could you please try the new version 3.8.3 - this should restore support for all stacks!

[danail-branekov]

Yes, it works with 3.8.3. Now we wait a java buildpack release to package this one.

Thanks!

[dmikusa]

This is resolved in ca-certificates 3.8.3.