[jira] [Commented] (CAMEL-24252) Container Version Upgrade workflow fails: metadata updater aborts PR loop

["Andrea Cosentino (Jira)" <ji...@apache.org>]

    [ 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)