oscerd opened a new pull request, #25088: URL: https://github.com/apache/camel/pull/25088
The scheduled [Container Version Upgrade](https://github.com/apache/camel/actions/workflows/check-container-versions.yml) workflow has failed on every run since 2026-06-29 ([28357095048](https://github.com/apache/camel/actions/runs/28357095048), [28775799343](https://github.com/apache/camel/actions/runs/28775799343), [29231474838](https://github.com/apache/camel/actions/runs/29231474838), [29723897415](https://github.com/apache/camel/actions/runs/29723897415)), so container image upgrade PRs stopped being opened. ## Root cause The `Create individual PRs for each container update` step loops over the outdated images and calls `update-metadata-version.py` unguarded. That script matched entries by `(artifactId, serviceVersion)` and `sys.exit(1)`-ed when nothing matched — and since the step runs under `bash -e`, the first container whose version has no `serviceVersion` counterpart aborted the entire loop. Every remaining container was skipped and the job went red. In the 2026-07-20 run the very first of 15 outdated containers triggered it, so zero PRs were created. Three cases can never match, and all three are legitimate no-ops: | Case | Example | Failing run | |---|---|---| | Platform-specific keys — `CamelTestInfraGenerateMetadataMojo` skips `.ppc64le`/`.s390x`/`.aarch64`/`.amd64`, so their version never reaches `metadata.json` | `ollama.container.ppc64le` v0.17.6 | 07-06, 07-13 | | Shared `*-common` module — `azure.container` lives in `camel-test-infra-azure-common`, but the entries carrying that `serviceVersion` are `camel-test-infra-azure-storage-blob`/`-queue` (alias `azure`) | `azure.container` 3.35.0 | 07-20 | | No entry, or `serviceVersion: null` | `mcp-everything`, `tensorflow-serving`, `triton`, `observability` | latent | ## Changes - **`update-metadata-version.py`** now resolves the target entries the way the Mojo derives `serviceVersion`: the bumped **property key prefix** (the part before `.container`, normalized) matched against the entry `aliasImplementation`/`alias`, instead of the module directory name. This makes the shared `*-common` case work — an `azure.container` bump correctly updates both azure storage entries. The existing old-version filter is kept, so entries sharing a service alias (`hive-mq` vs `hive-mq`+`sparkplug`) stay separated. - Platform-specific keys, version filters (`.version.exclude`/`.include`/`.freeze`) and non-container keys (`ollama.model`) are recognised as having no metadata counterpart and reported as a **no-op instead of an error**. A non-zero exit is now reserved for real errors (bad arguments, unreadable/invalid metadata). - The script takes the **property name** rather than the module name as first argument, which is what the alias matching needs. - **`check-container-versions.yml`** guards the call, so even a hard failure only warns and the remaining containers still get their PR. ## Testing - New `test_update_metadata_version.py` (17 tests, stdlib `unittest`, no new dependency) covering the shared-module case, every no-op class, alias/version disambiguation, the argument contract, and a round-trip assertion that the Jackson `DefaultPrettyPrinter` formatter still reproduces the committed `metadata.json` byte for byte. - New `pr-ci-scripts-validation.yml` runs them on PRs touching `.github/actions/check-container-upgrade/**` — the scripts had no CI coverage at all until now. - Verified end to end against the real `metadata.json` files: `azure.container 3.35.0 → 3.36.0` updates exactly the two azure entries in both files (2 changed lines each, no reformatting); `ollama.container.ppc64le`, `observability.perses.container`, `ollama.model`, `tensorflow.serving.container` and `mcp.everything.container` are clean no-ops with exit 0; `ollama.container`, `aws.container` (16 entries) and `hivemq.sparkplug.container` update as before. - Replayed all 46 container properties in `test-infra/` through the new matcher: every property that has a metadata target resolves to the correct entries, and every remaining one is a genuine no-op. No user-visible change, so no upgrade guide entry. --- _Claude Code on behalf of @oscerd_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
