Andrea Cosentino created CAMEL-24252:
----------------------------------------
Summary: Container Version Upgrade workflow fails: metadata
updater aborts PR loop
Key: CAMEL-24252
URL: https://issues.apache.org/jira/browse/CAMEL-24252
Project: Camel
Issue Type: Bug
Components: ci
Reporter: Andrea Cosentino
Assignee: Andrea Cosentino
The scheduled *Container Version Upgrade* workflow
({{.github/workflows/check-container-versions.yml}}) has failed on every run
since 2026-06-29 (4 consecutive weeks). As a result no container image upgrade
PRs are being opened any more.
Failing runs: 28357095048 (2026-06-29), 28775799343 (2026-07-06), 29231474838
(2026-07-13), 29723897415 (2026-07-20).
h3. Root cause
The _Create individual PRs for each container update_ step loops over the
outdated images and calls, unguarded:
{code}
python3 .github/actions/check-container-upgrade/update-metadata-version.py \
"$MODULE_NAME" "$OLD_VERSION" "$NEW_VERSION" "$METADATA_INFRA"
"$METADATA_CATALOG"
{code}
{{update-metadata-version.py}} matches metadata entries by {{(artifactId,
serviceVersion)}} and calls {{sys.exit(1)}} when nothing matched. The step runs
under {{bash -e}}, so the first container whose version cannot be mapped to a
{{metadata.json}} entry aborts the whole loop: every remaining container is
skipped and the job goes red.
There are three legitimate cases where no metadata entry can ever match:
# *Platform-specific properties* - e.g. {{ollama.container.ppc64le}} (v0.17.6),
{{milvus.container.ppc64le}}. {{CamelTestInfraGenerateMetadataMojo}} explicitly
skips keys ending in {{.ppc64le}} / {{.s390x}} / {{.aarch64}} / {{.amd64}}, so
those versions never appear in {{metadata.json}}. This caused the 2026-07-06
and 2026-07-13 failures.
# *Shared "common" modules* - {{azure.container}} is defined in
{{camel-test-infra-azure-common}}, but the entries carrying that
{{serviceVersion}} are {{camel-test-infra-azure-storage-blob}} and
{{camel-test-infra-azure-storage-queue}} (both alias {{azure}}). The module
directory name derived by the workflow never matches an {{artifactId}}, so the
update is a no-op and the script fails. This caused the 2026-07-20 failure.
# *Modules with no entry or a null serviceVersion* -
{{camel-test-infra-mcp-everything}}, {{camel-test-infra-tensorflow-serving}}
and {{camel-test-infra-triton}} have no {{@InfraService}} metadata entry at
all, and {{camel-test-infra-observability}} has {{serviceVersion: null}}
(multi-container module). These are latent triggers of the same abort.
h3. Steps to reproduce
# Wait for the Monday 06:00 UTC schedule, or trigger the workflow manually via
{{workflow_dispatch}}.
# Ensure at least one outdated image is a platform-specific property or belongs
to a shared {{*-common}} module (currently {{azure.container}} and
{{ollama.container.ppc64le}} both qualify).
# Observe the _Create individual PRs for each container update_ step.
h3. Expected behaviour
Every outdated container image gets its own PR. When a bumped property has no
corresponding {{serviceVersion}} in the generated {{metadata.json}} files
(platform-specific key, multi-container module, or no registered service), the
metadata update is simply a no-op and the workflow moves on to the next
container.
h3. Actual behaviour
The step fails with:
{noformat}
No metadata target was updated in:
test-infra/camel-test-infra-all/src/generated/resources/META-INF/metadata.json,
catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/test-infra/metadata.json
No matching entries for camel-test-infra-azure-common/3.35.0 in ...
Process completed with exit code 1.
{noformat}
The loop aborts, the remaining containers are never processed, and the job is
red. In the 2026-07-20 run the very first of 15 outdated containers triggered
it, so zero PRs were created.
h3. Proposed fix
* Align {{update-metadata-version.py}} with
{{CamelTestInfraGenerateMetadataMojo}}: resolve the target entries from the
bumped *property key prefix* matched against the entry {{alias}} /
{{aliasImplementation}} (which is how the Mojo derives {{serviceVersion}}),
instead of the module directory name. This fixes the shared {{*-common}} module
case.
* Skip platform-specific and version-metadata keys, exactly as the Mojo does.
* Exit 0 with an informational message when there is genuinely nothing to
update; reserve a non-zero exit for real errors (missing/unreadable/invalid
metadata file, bad arguments).
* Guard the invocation in the workflow so that a metadata update failure warns
but does not abort the remaining containers.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
