test: hardcode the 1.10.4 RC image, chart and catalog index - #5335
Open
gustavolira wants to merge 5 commits into
Open
test: hardcode the 1.10.4 RC image, chart and catalog index#5335gustavolira wants to merge 5 commits into
gustavolira wants to merge 5 commits into
Conversation
Pin every image reference the nightly jobs resolve at runtime so a run always exercises the 1.10.4 RC, regardless of what Gangway or the environment passes: - TAG_NAME=1.10-170 - IMAGE_REGISTRY=quay.io - IMAGE_REPO=rhdh/rhdh-hub-rhel9 - CHART_VERSION=1.10-170-CI - CATALOG_INDEX_IMAGE=quay.io/rhdh/plugin-catalog-index:1.10-102 openshift-ci-tests.sh no longer resolves the chart version from the branch. Cluster configuration is untouched; the cluster still comes from the pool. Not for merge. Verification aid for RHIDP-16019.
|
Contributor
|
The container image build workflow finished with status: |
The AKS, EKS and GKE deployment scripts build their own helm upgrade command and set only upstream.backstage.image.*. They never set global.catalogIndex.image.*, so on those platforms the value file decides the catalog index and the floating "1.10" tag wins over the RC. Pin it to 1.10-102 in values_showcase.yaml and values_showcase-rbac.yaml. The OCP Helm and Operator paths already pass the same value through helm::get_image_params and operator.sh, so nothing conflicts. This PR changes only CI scripts and value files, so the container image does not need rebuilding.
gustavolira
force-pushed
the
test/hardcode-rc-1.10-170
branch
from
September 2, 2026 16:59
49afcf5 to
46dea7f
Compare
Member
Author
|
/test ? |
Contributor
|
The container image build workflow finished with status: |
Contributor
Member
Author
|
/test e2e-ocp-helm-nightly |
1 similar comment
Member
Author
|
/test e2e-ocp-helm-nightly |
The showcase-runtime phase started Playwright as soon as `helm upgrade`
returned, without waiting for the deployment to become ready. The first
test in the `showcase-runtime-db` dependency project scales the
deployment to 0, which killed the `install-dynamic-plugins` init
container while it was still installing.
That script takes a lock file on the `dynamic-plugins-root` PVC and
releases it through an `atexit` handler, which does not run when the
container is killed. The lock survived on the PVC, and every pod created
afterwards blocked forever on:
======= Waiting for lock release (file: /dynamic-plugins-root/install-dynamic-plugins.lock)...
Each Azure DB test then burned its full 10 minute timeout waiting for a
pod that could never become ready. Ten attempts consumed 100 minutes and
the job hit the Prow timeout inside this phase, so
`showcase-sanity-plugins` never ran.
Swap `testing::run_tests` for `testing::check_and_test` in both the OCP
Helm and OCP Operator runtime phases. It gates on `/healthcheck` before
starting the tests, so the initial plugin install always completes before
anything scales the deployment down, and it collects pod logs when the
tests fail.
Also reformat two comment alignments in env_variables.sh that
`yarn prettier:check` flags.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
install-dynamic-plugins.py takes a lock file in dynamic-plugins-root and
releases it from an atexit handler. install-dynamic-plugins.sh forwards
SIGTERM to the process group (RHDHBUGS-3449), so a graceful shutdown
still releases it, but a hard kill - grace period expiry, eviction, OOM,
node failure - skips atexit entirely. When dynamic-plugins-root is a PVC
the lock file outlives the container, and wait_for_lock_release is an
unbounded `while True` with no staleness check, so every later container
blocks on it forever.
The showcase-runtime phase hit exactly this: the first test scaled the
deployment down while the initial install was still running, and every
pod after that printed only
======= Waiting for lock release (file: /dynamic-plugins-root/install-dynamic-plugins.lock)...
The holder now refreshes the lock's mtime from a daemon thread every 10s,
and a waiter that sees no refresh for 60s reports it and breaks the lock.
remove_lock tolerates a missing file, which also silences the spurious
FileNotFoundError when the process exits before acquiring the lock.
Separately, align restartDeployment's internal budgets with the 10 minute
timeout its callers set: 5m + 10s + 10m could not fit, so Playwright
killed the worker mid-restart, the catch block never logged pod
conditions or events, and the retry scaled the deployment down again on
top of a rollout that was still starting. 2m + 10s + 7m fits.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
SonarCloud flagged the new os.remove in wait_for_lock_release: the path descends from argv, so a caller could in principle point it anywhere. Route both removals through remove_lock, which now rejects any path whose basename is not install-dynamic-plugins.lock and rebuilds the path from the validated directory. There is a single os.remove left, and it can only ever delete a lock file. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
|
| print(f"======= Removed lock file: {lock_file_path}") | ||
|
|
||
| # Wait for the lock file to be released | ||
| # Wait for the lock file to be released, or break it when its holder is gone |
Member
Author
|
/test e2e-ocp-helm-nightly |
|
@gustavolira: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
|
PR needs rebase. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
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.
Pins every image reference the nightly jobs resolve at runtime. A run now exercises the 1.10.4 RC whatever Gangway or the environment passes.
Hardcoded in
.ci/pipelines/env_variables.sh:TAG_NAME1.10-170IMAGE_REGISTRYquay.ioIMAGE_REPOrhdh/rhdh-hub-rhel9CHART_VERSION1.10-170-CICATALOG_INDEX_IMAGEquay.io/rhdh/plugin-catalog-index:1.10-102.ci/pipelines/openshift-ci-tests.shno longer resolves the chart version from the branch. It assigns the pinned value and logs it.This PR changes no cluster configuration. The cluster still comes from the pool.
Not for merge. It serves RHIDP-16019, which verifies the 1.10.4 RC against the automated e2e suite.