I dont see a github workflow to publish docker image in the PR. But I think it would be good to publish with this feature enabled.
We can include in the iceberg-rest-fixture docker publish github workflow, https://github.com/apache/iceberg/blob/main/.github/workflows/publish-iceberg-rest-fixture-docker.yml On Fri, Feb 20, 2026 at 8:47 AM Robin Moffatt via dev < [email protected]> wrote: > Great. I'm happy to have a go at adding that. > Do you think that should be a pre-req for this PR [1]? Or done > subsequently? > > [1]: https://github.com/apache/iceberg/pull/15212 > > On Fri, 20 Feb 2026 at 15:02, Kevin Liu <[email protected]> wrote: > >> Sounds like a good idea to incorporate trivy. There are other apache >> projects using trivy as part of their build/publish step for docker >> containers. Heres one from apache/superset, >> https://github.com/apache/superset/blob/9f8b212ccc75308d019338fab642489bda00af3d/.github/workflows/docker.yml#L104-L119 >> >> We can emulate that in our pipeline >> >> On Fri, Feb 20, 2026 at 2:29 AM Robin Moffatt via dev < >> [email protected]> wrote: >> >>> Hi Dan, >>> Thanks for the review on the PR. >>> >>> One thing that's come up internally is that the Confluent team use trivy >>> [1] to scan for CVEs as a mandatory step before listing a connector. This >>> has flagged CVEs previously (e.g. [2]) that needed patching. >>> >>> Can you suggest what the best way to incorporate this into the release >>> workflow might be? >>> As it stands, it's only the finalised release that's sent to Confluent >>> and then scanned; should the trivy step be further upstream in the release >>> process so that CVEs are patched before the final release is made? >>> >>> thanks, Robin. >>> >>> [1] https://trivy.dev/ >>> [2] https://github.com/apache/iceberg/pull/14985 >>> >>> On Thu, 19 Feb 2026 at 01:07, Daniel Weeks <[email protected]> wrote: >>> >>>> I'll take a look tomorrow. This would be great to land and validate >>>> with the 1.11 release. >>>> >>>> -Dan >>>> >>>> On Mon, Feb 16, 2026, 4:24 AM Robin Moffatt <[email protected]> wrote: >>>> >>>>> Hi Dan, >>>>> I've addressed your comments on the PR, could you take another look >>>>> please? >>>>> >>>>> Thanks, Robin >>>>> >>>>> On Fri, 6 Feb 2026 at 19:29, Daniel Weeks <[email protected]> wrote: >>>>> >>>>>> Hey Robin, >>>>>> >>>>>> Sorry for not responding to the last email, but this looks like the >>>>>> right approach. A couple small comments on the PR, but other than that >>>>>> this looks good. >>>>>> >>>>>> -Dan >>>>>> >>>>>> On Mon, Feb 2, 2026 at 9:02 AM Robin Moffatt via dev < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> I've reworked the process based on the feedback into: >>>>>>> 1. Add the Kafka Connect artifact to maven as part of gradle release >>>>>>> 2. The version from Maven is what gets sent to Confluent Hub >>>>>>> >>>>>>> Please take a look: https://github.com/apache/iceberg/pull/15212 >>>>>>> >>>>>>> thanks, Robin. >>>>>>> >>>>>>> On Fri, 30 Jan 2026 at 06:37, Robin Moffatt <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Daniel, >>>>>>>> >>>>>>>> I appreciate your input and guidance. I'd definitely missed the >>>>>>>> released artifacts and provenance angle here. >>>>>>>> >>>>>>>> So would the right direction here be to include the Kafka Connect >>>>>>>> artifact as part of the gradle release command? >>>>>>>> Then once the release has passed, the artifact on maven can be >>>>>>>> submitted to Confluent Hub directly by the release manager. >>>>>>>> >>>>>>>> If this sounds right I'm happy to put together a PR for it. >>>>>>>> >>>>>>>> thanks, Robin >>>>>>>> >>>>>>>> On Thu, 29 Jan 2026 at 22:23, Daniel Weeks <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I added some comments to this effect in the PR, but it's probably >>>>>>>>> good to highlight this here. >>>>>>>>> >>>>>>>>> I don't think we should be generating new artifacts to upload to >>>>>>>>> connect/hub, but rather referencing the voted and released artifacts >>>>>>>>> that >>>>>>>>> are part of the release process. >>>>>>>>> >>>>>>>>> It might be good to include the instructions on how this fits into >>>>>>>>> the release process <https://iceberg.apache.org/how-to-release/> >>>>>>>>> so we understand the full workflow along with the script. >>>>>>>>> >>>>>>>>> -Dan >>>>>>>>> >>>>>>>>> On Thu, Jan 29, 2026 at 6:24 AM Robin Moffatt via dev < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Could I ask for input on this please, or a review of the PR[1]? >>>>>>>>>> >>>>>>>>>> thanks, Robin. >>>>>>>>>> >>>>>>>>>> [1] https://github.com/apache/iceberg/pull/15113 >>>>>>>>>> >>>>>>>>>> On Thu, 22 Jan 2026 at 17:20, Robin Moffatt <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Currently, the version of the Iceberg connector for Kafka >>>>>>>>>>> Connect on Confluent Hub is outdated (1.9.2). Confluent staff >>>>>>>>>>> manually >>>>>>>>>>> uploaded it through an ad-hoc process, which we would like to help >>>>>>>>>>> the Apache Iceberg community formalise. >>>>>>>>>>> Previously, Tabular owned the connector, and its inclusion >>>>>>>>>>> in Confluent Hub was managed through the commercial partnership >>>>>>>>>>> between the >>>>>>>>>>> two companies. >>>>>>>>>>> >>>>>>>>>>> I've put together a draft PR [1] with a script that builds and >>>>>>>>>>> packages the connector for submission to Confluent Hub [2] (now >>>>>>>>>>> called >>>>>>>>>>> Confluent Marketplace). >>>>>>>>>>> >>>>>>>>>>> Please review the PR's proposed process, and let me know what >>>>>>>>>>> you think. I'm happy to liaise between the community and the >>>>>>>>>>> Confluent team >>>>>>>>>>> here to find a process that works for everyone. >>>>>>>>>>> >>>>>>>>>>> thanks, >>>>>>>>>>> Robin >>>>>>>>>>> >>>>>>>>>>> 1: https://github.com/apache/iceberg/pull/15113 >>>>>>>>>>> 2: https://hub.confluent.io >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> > >
