[
https://issues.apache.org/jira/browse/CAMEL-24252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrea Cosentino resolved CAMEL-24252.
--------------------------------------
Resolution: Fixed
> 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
> Priority: Major
> Fix For: 4.22.0
>
>
> 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)
