[VietND96]

Summary

Follow-up to #3274 / #3275. That issue happened because update_tag_in_docs_and_files.sh's whole-tree sed "s/${LATEST_TAG}/${NEXT_TAG}/g" only matches when LATEST_TAG is the exact string still embedded in the files. Once a wrong LATEST_TAG (or anything else) makes it miss once, every later release searches for a tag that's never actually there, and the chart's default image tags drift silently - for three releases, in this repo's actual history - with nothing in CI to signal it.

This hardens the script itself so the same class of bug can't recur unnoticed:

1. Fail loudly instead of drifting silently. After the rewrite, assert that charts/selenium-grid/values.yaml's imageTag and nodesImageTag actually equal NEXT_TAG, and exit 1 with a clear message if not. I verified this two ways against a real Linux container (GNU find/sed, matching what the GitHub Actions runners use):

   • Running with the real previous tag (4.48.0-20260905 → 4.51.0-20261010, the [ci] Catch up stale default image tags to 4.51.0-20261010 #3275 catch-up) exits 0 and produces the correct rewrite.
   • Running with the wrong LATEST_TAG that actually caused [🐛 Bug]: Chart values.yaml image tags stuck at 4.48.0-20260905 since 0.60.0 - chart upgrades no longer bring new images #3274 (4.48.0-20261010, the lexically-highest-but-never-shipped tag the old sort-based resolution picked) now exits 1 with: ./charts/selenium-grid/values.yaml's imageTag was not updated to 4.51.0-20261010. LATEST_TAG (4.48.0-20261010) probably doesn't match what's actually in the file - fix it manually before releasing. Previously this scenario exited 0 and shipped stale defaults silently - that's exactly what happened in production.

2. Stop the sed from corrupting files it shouldn't touch. A full end-to-end run (not just the hand-reviewed [ci] Catch up stale default image tags to 4.51.0-20261010 #3275 catch-up) surfaced two real false-positive targets:

   • charts/selenium-grid/multiple-nodes-platform-version.yaml and its test copy tests/charts/ci/multiple-nodes-platform-version-values.yaml pin per-Chrome-version image tags (146.0-<date>, 145.0-<date>, ...), dated independently of the Grid release by their own browser-version release process. Their date collides with the Grid release's date often enough that the bare-date pass was rewriting dates that were never actually built for those specific browser versions.
   • .github/workflows/deploy.yml's only tag-shaped strings are inside one comment narrating this exact past incident, by its specific tag values (explaining why LATEST_TAG resolution moved from git tag --sort to git describe). Every later release's LATEST_TAG eventually matches one of those literals, silently turning the incident report into a false account of its own history - I caught this happening again during testing for [ci] Catch up stale default image tags to 4.51.0-20261010 #3275's catch-up and reverted it there by hand, but the script would keep doing it forever without this exclusion.

Test plan

• bash -n syntax check.
• make lint_format_scripts (shfmt) makes no further changes.
• Full end-to-end run in a real ubuntu:24.04 container against a throwaway copy of the repo at its pre-[ci] Catch up stale default image tags to 4.51.0-20261010 #3275 (stale) state, with the real previous tag: exits 0, matches [ci] Catch up stale default image tags to 4.51.0-20261010 #3275's hand-reviewed result exactly (values.yaml fixed, the three newly-excluded files untouched).
• Same setup with the actual wrong tag that caused [🐛 Bug]: Chart values.yaml image tags stuck at 4.48.0-20260905 since 0.60.0 - chart upgrades no longer bring new images #3274: exits 1 with the new, actionable error.

🤖 Generated with Claude Code

[qodo-code-review]

ⓘ Qodo reviews are paused because the subscription is no longer active. Ask your workspace admin to reactivate the subscription to resume reviews. Manage billing

[VietND96]

Added one more fix while bumping the chart for #3275 (PR #3275 bumps charts/selenium-grid/Chart.yaml to publish that fix - helm-chart-release.yml only triggers on changes to that file).

While checking what a chart-coupled release actually does, found that this script's "bump chart version" step has its own version of the same class of bug: sed -i "s/${latest_chart_version}/${next_chart_version}/g" uses the chart version as a sed pattern (regex), where . matches any character. An unescaped three-part version like 0.60.0 can match an unrelated 6-digit substring - and did, repeatedly, in .github/ISSUE_TEMPLATE/bug_report.yml's version placeholder:

• 4.48.0-20260905? Please use... → (chart 0.60.0→0.61.0) → 4.48.0-20.61.05? Please...
• → (chart 0.61.0→0.62.0) → 4.48.0-20.62.05? Please...

Fixed by escaping the version string before using it as the sed pattern. Verified by replaying the exact historical scenario that caused the corruption (LATEST_TAG=4.48.0-20260905, NEXT_TAG=4.49.0-20260909, chart 0.60.0) in a real container: Chart.yaml now bumps 0.60.0 → 0.61.0 cleanly and the placeholder updates to 4.49.0-20260909? ... instead of the garbled ...20.61.05....