Skip to content

try Andy's patch for tde and build a new image - #5

Open
Manika-Percona wants to merge 3 commits into
mainfrom
dev/tde_patch
Open

try Andy's patch for tde and build a new image#5
Manika-Percona wants to merge 3 commits into
mainfrom
dev/tde_patch

Conversation

@Manika-Percona

Copy link
Copy Markdown
Collaborator

No description provided.

@CLAassistant

CLAassistant commented Jul 29, 2026

Copy link
Copy Markdown

CLA assistant check
All committers have signed the CLA.

@github-actions

github-actions Bot commented Jul 29, 2026

Copy link
Copy Markdown

OBS Build Check — ✅ Builds passed

Packages for this PR are being built at isv:percona:PR:pr-5.

Packages
Built from PR sources 9
Reused from main binaries 106
Repository ✔ Succeeded ✗ Failed ⛔ Broken ⚠ Unresolvable — Excluded
UBI_9 18 0 0 0 0
ubi9 8 0 0 0 0
Total 26 0 0 0 0

Updated: 2026-07-29 16:09 UTC

rjd15372 added a commit that referenced this pull request Jul 29, 2026
The --branch-from content check compares raw file md5s against OBS.  For
packages with a cargo_vendor service whose upstream ships no Cargo.lock
(pgvectorscale), cargo vendor re-resolves the crate graph on every run, so
vendor.tar.gz bytes track the crates.io state at generation time and differ
between machines and dates even when no real input changed (verified:
identical back-to-back local runs, but OBS rev5 vendored camino-1.2.4 while
a fresh run vendors camino-1.2.5).

Seen on percona/obs-packaging PR #5: a PR touching only ppg:staging:18
packages promoted percona-pgvectorscale in staging:16/17/18:extras because
the content check reported 'vendor.tar.gz differs' (the gate before it fell
through to the content check because the OBS sync comments record SHAs from
a fork checkout that do not exist in the CI clone).

Compare vendor.tar.* by presence instead of bytes when the package declares
a cargo_vendor service and both sides have the archive: it is a derived
artifact of the other uploaded files, so if those all match, a vendor byte
difference is pure resolution drift and must not flip an aggregate decision
to promote.  A vendor archive missing from either side is still a mismatch.

The comparison is extracted into _content_mismatches so it is unit-testable
and reports every differing file instead of stopping at the first.

Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
rjd15372 added a commit that referenced this pull request Jul 29, 2026
Packages synced to OBS before the migration from
rjd15372/percona-obs-packaging to percona/obs-packaging carry sync
comments like 'sync: main@6f95b5a (rjd15372/...)' whose SHAs come from the
legacy repo's rebased history and do not exist in a percona-only clone.
The branch-decision/skip fast path runs git log <sha>..HEAD per package, so
an unresolvable SHA conservatively falls through to the full content check:
every PR run re-ran services for essentially the whole tree (~10 min), and
it also exposed the vendor.tar.gz drift promotions on PR #5.

The two histories share ancestry up to the migration point, so simply
fetching the legacy refs makes the old SHAs resolvable and the range
queries correct: verified in a percona-only clone that after the fetch
6f95b5a..HEAD is empty for untouched packages (fast aggregate) and still
lists the PR commits for packages the PR really changed.

The fetch is fail-open (warning only) and should be dropped once all
packages have been re-synced with percona/obs-packaging SHAs in their
comments.

Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

obs-sync Trigger OBS sync push ubi9-images UBI_9

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants