confluent-kafka/7.9.0.82 package update

[octo-sts]

[debasishbsws]

The expected commit did not change because it is using release monitor instead of GitHub. But how the build is getting pass?
Log:

2024/09/09 12:54:03 INFO [git checkout] repo='https://github.com/confluentinc/kafka' dest='.' depth='1' branch='' tag='v7.9.0-82-ccs' expcommit='cbc25f70cb7fe8a4c54933db073a131384438bdb' recurse='false'

expcommit='cbc25f70cb7fe8a4c54933db073a131384438bdb' is not matching with the Yaml

expected-commit: f8bb9e72b99fd4b472aadc9df349ed3aed2af0e7

[debasishbsws]

It is not passing anymore local build

[philroche]

@debasishbsws Are you suggesting this is a bug in the bump or in the use of release monitor?

[debasishbsws]

@philroche I have no clue. in the pipeline where it take the expected commit from the yaml(Which is incorrect in this case) it is showing a different one(the correct one).

The melange build should have failed, but it has passed.

Maybe this is a ones in a millions but still the build should not pass.
Fixing this is easy but why did it pass in the first place is a bit concerning.

[philroche]

@debasishbsws Can you create an issue and escalate it to the Lifecycle team to understand why there was no expected commit change?

[debasishbsws]

@mamccorm this will fail the build, the package is not building. It just build one time in this CI

[debasishbsws]

@philroche the reason for why the expected commit has not change is pretty clear. we are using release monitor for this package to update, which do not return an expected-commit from the API.

[mamccorm]

I flipped it over to git poller in a previous commit:

• confluent-kafka/7.9.0.82 package update #27939

Sorry should have linked here originally. The package looks to have built and an [updated image ](https://apk.dag.dev/https/packages.wolfi.dev/os/aarch64/confluent-kafka-7.9.0.82-r0.apk@sha1:e6bcf120c5677062bdf03ea5d896b0a4ce4dcbf2/

• cgr.dev/chainguard/confluent-kafka:latest)as well

[debasishbsws]

@mamccorm Oh okay.

[philroche]

@debasishbsws @mamccorm I'm unsure what the outcome is here though. Should the expected commit have changed in this PR? The move to using git: suggests that it should have changed?

PR #27939 bumped to the same version yet this PR still has a diff?

[mamccorm]

I should have a ran a rebase before merge so that'd explain the diff version. Now we've migrated over to Git, lets see if the digest issue occurs in the next bump. Confluent setup allow-lists for access to their API for polling for updates, which was blocking traffic from the public GH runner IP pools. I'd not be surprised if it was also partially blocking traffic from release monitor