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

["Claus Ibsen (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CAMEL-24252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Claus Ibsen updated CAMEL-24252:
--------------------------------
    Issue Type: Task  (was: Bug)

> 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: Task
>          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)