[
https://issues.apache.org/jira/browse/CAMEL-24252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18098829#comment-18098829
]
Andrea Cosentino commented on CAMEL-24252:
------------------------------------------
PR opened: https://github.com/apache/camel/pull/25088
The metadata updater now resolves entries the way
CamelTestInfraGenerateMetadataMojo derives serviceVersion (property key prefix
against the entry aliases) instead of the module directory name, so shared
container.properties files such as azure.container are handled. Bumps with no
metadata counterpart (platform-specific keys, multi-container modules, modules
with no @InfraService entry) are reported as a no-op instead of an error, and
the workflow no longer aborts the remaining containers if the update fails.
_Claude Code on behalf of oscerd_
> 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
>
> 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)
