Repository navigation
Not for merge: CI proof (upgrade-mutation) - #4499
Closed
erikdarlingdata wants to merge 4 commits into
Closed
erikdarlingdata wants to merge 4 commits into
erikdarlingdata wants to merge 4 commits into
Conversation
…'s schema or upgrade path The gated upgrade-in-place and same-major-swap E2Es (#1706, #3906) only ran on the nightly job: pull-request CI never built the upgrade fixture or set the three env vars those tests read, so they silently skipped on every PR. Adds a store-upgrade path filter derived from what those E2Es exercise (the store schema, the service project holding DarlingManagedPostgres and DarlingStoreUpgrade plus the managed-conf migration machinery, the two fixture scripts, and the workflow/filter files themselves). When a PR's changed files match it, build.yml's darling-pg job builds the same fixture nightly.yml builds and sets DARLING_TEST_PGRUNTIME_OLD/_NEWZIP/_PREVIOUS on the shards that carry the gated classes; other shards and non-matching PRs are unaffected. Pins the filter's existence and coverage in DarlingPathFilterGateTests. nightly.yml is unchanged.
…-upgrade E2E only) The real pass drops the -o/-O listen_addresses=localhost + TimescaleDB quiesce override that BuildPgUpgradeArguments_QuiescesTimescaleOnBothClusters and BuildPgUpgradeArguments_RestoresDualStackLoopbackForTheUpgradeWindow pin against BuildPgUpgradeArguments directly (unit level, always runs). This mutation removes the argument at the ONE call site that matters: the real pg_upgrade invocation, several thousand lines away from the unit-level pins, which still pass. Only the gated in-place-upgrade E2E (which drives the real call site through EnsureRunningAsync end to end) can catch that this specific wiring regressed, because Windows silently resolves 'localhost' to ::1 for pg_upgrade's own dial and the store's real conf binds 127.0.0.1 only \u2014 the hang this whole path exists to prevent.
The fixture steps and the three DARLING_TEST_PGRUNTIME_* env expressions were gated on matrix.shard != 0 because today's upgrade classes happen to hash into shards 1 and 2. That meant a renamed class, or a new upgrade E2E that hashes into shard 0, would silently skip the fixture with no signal. A class's shard must never decide whether it runs.
…i-proof/upgrade-mutation
Owner
Author
|
Closing: CI proof recorded on the real PR. |
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
1 participant
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.
Not for merge. A CI proof for the change on
ci/pr-store-upgrade-legs(running the store-upgrade tests in pull-request CI). This PR is closed and its branch deleted once CI reports.A one-line break at the in-place upgrade call site. Expected: the upgraded-in-place test goes RED in PR CI.