mirror of
https://github.com/quay/quay.git
synced 2026-10-24 21:59:23 +03:00
f845fb766c
RunBridge previously had zero success-path test coverage: the old bridge_test.go (deleted in #6681) proved idempotence against a synthetic current-schema fixture with its alembic_version hand-edited to "3f8d7acdf7f9" - not a database that ever existed as a shipped OMR schema. compatibility_test.go/bridge.go only exercised rejection paths. This adds a real artifact-derived fixture and gives RunBridge actual convergence coverage against it. Fixture provenance ------------------- - Source: mirror-registry-offline.tar.gz v2.0.11 (https://github.com/quay/mirror-registry/releases/tag/v2.0.11) sha256:bc39dae5efd5561db3c063d2cfb9b462f8389febbbe88bfdaf831b662f9d0bba - Installed image: registry.redhat.io/quay/quay-rhel8:v3.12.18 (pulled amd64 manifest digest sha256:ef416c4a2dbc03753a3552d3ac22adbd4e1ecbae4312d1d915609cef53c7668e; the multi-arch manifest-list digest for this tag is sha256:b6839e49202f29dd430cf53327061987737fedfe370d843b10434b203ef95755) - Extraction: installed the offline package via podman on a disposable RHEL host, pushed three small synthetic tags for data-invariant coverage (a plain tag, plus two tags sharing one manifest digest), then pulled quay_sqlite.db from the sqlite-storage volume. Two host-specific gotchas worth recording for anyone repeating this: the installer's self-signed cert only carries DNS-name SANs, so --quayHostname must be a hostname like "localhost" rather than a raw IP or Quay's own HostSettings config validation fails and quay-app crash-loops; and this RHEL host's default /etc/containers/policy.json requires sigstore signature verification for registry.access.redhat.com, so `podman push` of a pulled image needs --remove-signatures or it fails with "would invalidate signatures" (a permissive CI-runner policy.json wouldn't hit this). - Observed alembic_version: 3f8d7acdf7f9 - confirms (rather than assumes) that this OMR release resolves to the same Alembic head as the matching public quay/quay v3.12.18 source tag. - PRAGMA integrity_check and PRAGMA foreign_key_check both passed on the untouched extract before sanitization. - Sanitization: user.password_hash, robotaccounttoken.token, accesstoken.token_code, appspecificauthtoken.token_secret, oauthaccesstoken.token_code, oauthapplication.secure_client_secret, and oauthauthorizationcode.code_credential were replaced with fixed placeholder strings before VACUUM and `sqlite3 .dump`. No other columns were modified. Every row in the fixture is synthetic install-time output or the three pushed test tags; there is no real customer data. - internal/dal/dbcore/testdata/omr_v2.0.11_3f8d7acdf7f9.sql: 1590 lines, 344 INSERT statements. New tests (internal/dal/dbcore/fixture_test.go) ------------------------------------------------ - TestRunBridge_ConvergesArtifactFixture: RunBridge against the real fixture reaches TargetVersion, PRAGMA integrity_check/foreign_key_check pass before and after, repository/tag/manifest row counts are unchanged, and all bridgeColumns/bridgeIndexFixes entries plus the bridge SQL's new tables exist afterward. - TestRunBridge_RejectsMarkerTamperedArtifactFixture and TestRunBridge_RejectsStructurallyAlteredArtifactFixture: a copy with a tampered alembic_version marker, and a copy missing a table bridgeColumns' ensureColumn targets directly, both fail closed via RunBridge/applyBridge's existing error paths. No new structural-profile check was added to production code for this; wiring the fixture's schema fingerprint into ValidateSourceCompatibility's runtime admission remains separate, deferred follow-up work. Non-goals --------- No changes to ValidateSourceCompatibility/RunBridge production logic, no migration ledger, no changes to .github/workflows/ci-go.yaml's real e2e-migrate job (which continues to install and migrate a freshly downloaded v2.0.11 artifact on every CI run, independent of this fixture). The one-off extraction script used to produce this fixture is not checked in: every OMR v2.0.x release resolves to the same Alembic head, so regenerating this exact fixture is unlikely; a future schema-changing OMR release would need fresh analysis and steps anyway, not a rerun of this file. Verification: - go test ./internal/dal/dbcore ./internal/migrate -count=1 - go vet ./... - go build ./... - git diff --check