Repository navigation
CAMEL-24252: Fix the container upgrade workflow aborting the PR loop - #25088
Merged
Merged
Conversation
update-metadata-version.py exited 1 whenever no metadata entry matched, and the workflow step runs under bash -e, so the first container whose version has no serviceVersion counterpart aborted the whole loop: the remaining containers never got a PR and the job went red. Match the entries the way CamelTestInfraGenerateMetadataMojo derives serviceVersion — the property key prefix against the entry aliases — instead of the module directory name, so a container.properties shared across modules (azure.container, owned by camel-test-infra-azure-common but feeding the azure-storage-blob and azure-storage-queue entries) is resolved. Platform-specific keys, version filters and properties with no metadata counterpart are now reported as a no-op instead of an error, and the workflow keeps going if the update fails anyway. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Andrea Cosentino <ancosen@gmail.com>
Contributor
|
🌟 Thank you for your contribution to the Apache Camel project! 🌟 🐫 Apache Camel Committers, please review the following items:
|
davsclaus
approved these changes
Jul 24, 2026
Contributor
|
ℹ️ CI did not run targeted module tests. 🔬 Scalpel shadow comparison — Scalpel: 649 tested, 29 compile-only — current: 0 all testedMaveniverse Scalpel detected 678 affected modules (current approach: 0).
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The scheduled Container Version Upgrade workflow has failed on every run since 2026-06-29 (28357095048, 28775799343, 29231474838, 29723897415), so container image upgrade PRs stopped being opened.
Root cause
The
Create individual PRs for each container updatestep loops over the outdated images and callsupdate-metadata-version.pyunguarded. That script matched entries by(artifactId, serviceVersion)andsys.exit(1)-ed when nothing matched — and since the step runs underbash -e, the first container whose version has noserviceVersioncounterpart aborted the entire loop. Every remaining container was skipped and the job went red. In the 2026-07-20 run the very first of 15 outdated containers triggered it, so zero PRs were created.Three cases can never match, and all three are legitimate no-ops:
CamelTestInfraGenerateMetadataMojoskips.ppc64le/.s390x/.aarch64/.amd64, so their version never reachesmetadata.jsonollama.container.ppc64lev0.17.6*-commonmodule —azure.containerlives incamel-test-infra-azure-common, but the entries carrying thatserviceVersionarecamel-test-infra-azure-storage-blob/-queue(aliasazure)azure.container3.35.0serviceVersion: nullmcp-everything,tensorflow-serving,triton,observabilityChanges
update-metadata-version.pynow resolves the target entries the way the Mojo derivesserviceVersion: the bumped property key prefix (the part before.container, normalized) matched against the entryaliasImplementation/alias, instead of the module directory name. This makes the shared*-commoncase work — anazure.containerbump correctly updates both azure storage entries. The existing old-version filter is kept, so entries sharing a service alias (hive-mqvshive-mq+sparkplug) stay separated..version.exclude/.include/.freeze) and non-container keys (ollama.model) are recognised as having no metadata counterpart and reported as a no-op instead of an error. A non-zero exit is now reserved for real errors (bad arguments, unreadable/invalid metadata).check-container-versions.ymlguards the call, so even a hard failure only warns and the remaining containers still get their PR.Testing
test_update_metadata_version.py(17 tests, stdlibunittest, no new dependency) covering the shared-module case, every no-op class, alias/version disambiguation, the argument contract, and a round-trip assertion that the JacksonDefaultPrettyPrinterformatter still reproduces the committedmetadata.jsonbyte for byte.pr-ci-scripts-validation.ymlruns them on PRs touching.github/actions/check-container-upgrade/**— the scripts had no CI coverage at all until now.metadata.jsonfiles:azure.container 3.35.0 → 3.36.0updates exactly the two azure entries in both files (2 changed lines each, no reformatting);ollama.container.ppc64le,observability.perses.container,ollama.model,tensorflow.serving.containerandmcp.everything.containerare clean no-ops with exit 0;ollama.container,aws.container(16 entries) andhivemq.sparkplug.containerupdate as before.test-infra/through the new matcher: every property that has a metadata target resolves to the correct entries, and every remaining one is a genuine no-op.No user-visible change, so no upgrade guide entry.
Claude Code on behalf of @oscerd