Skip to content

fix(oss-commit-sync): stop reporting our own exports as lost trailers - #207

Merged
sydorovdmytro merged 1 commit into
mainfrom
devops-1238/anchor-heal-classify-exports
Jul 31, 2026
Merged

fix(oss-commit-sync): stop reporting our own exports as lost trailers#207
sydorovdmytro merged 1 commit into
mainfrom
devops-1238/anchor-heal-classify-exports

Conversation

@sydorovdmytro

Copy link
Copy Markdown
Contributor

Summary

A green sync-from-oss run on vcluster-pro printed:

::notice::Anchor healed from content: 887d668e -> c6abe8ca (4 OSS commit(s) already
present in staging/github.com/loft-sh/vcluster but not recorded by a readable
Oss-Commit trailer).

All 4 commits carried a Monorepo-Commit trailer: our own exports. Their content is in staging/ because that is where it was authored, and they will never carry an Oss-Commit trailer, because that trailer records an import. content_anchor did not distinguish them from external commits, so the notice fired after every export with a count that grew until the next external import recorded a fresh trailer, and health reported the same range as stale-anchor.

A genuine trailer loss (squash-merged sync PR) produces the identical message, so the annotation that has to stay trustworthy was the one crying wolf.

  • classify_healed_range splits the healed range by provenance: Monorepo-Commit present means our export (expected), neither trailer means an import whose record was lost.
  • Import annotates only the unrecorded case and points at the merge method; healing over our own exports is a plain log line.
  • Health judges stale-anchor on the unrecorded count alone and reports both classes in the step summary.
  • New outputs: healed-export-count, healed-unrecorded-count, redundant-export-count, redundant-unrecorded-count. healed-count / redundant-count keep their totals.

Test plan

  • make test-oss-commit-sync — 64 tests pass, including three new cases: export-only healing (no ::notice::), a mixed range (1 export + 1 unrecorded, notice fires), and health treating an export-only lag as stale-anchor=false. The existing lost-trailer case now also asserts the unrecorded classification.
  • make check-docs clean, make lint (actionlint + zizmor) clean, shellcheck adds no new findings.

Follow-up

Merging does not ship this: oss-commit-sync/v1 must be advanced to the merged commit, otherwise vcluster-pro's sync-from-oss and sync-to-oss keep running the old code.

Closes DEVOPS-1238

Content healing advances the import anchor over every OSS commit whose
content the subtree already holds. After any export that includes the
commits we exported ourselves: they carry Monorepo-Commit and, by
design, never an Oss-Commit trailer, because that trailer records an
import. The import then annotated

  ::notice::Anchor healed from content: <a> -> <b> (4 OSS commit(s)
  already present in staging/... but not recorded by a readable
  Oss-Commit trailer)

on a run where nothing was wrong, and re-fired it with a growing count
until the next external import recorded a fresh trailer. The health
direction reported the same range as stale-anchor. A real trailer loss
produces the identical message, so the annotation that has to stay
trustworthy was the one being cried wolf on.

Split the healed range by provenance instead: commits carrying
Monorepo-Commit are our exports (expected, plain log line), commits
carrying neither trailer are imports whose provenance record was lost
(annotated, and pointed at the merge method). Health judges
stale-anchor on the unrecorded count alone and reports both classes in
its step summary.

New outputs: healed-export-count, healed-unrecorded-count,
redundant-export-count, redundant-unrecorded-count.

Closes DEVOPS-1238
@sydorovdmytro
sydorovdmytro requested a review from Piotr1215 as a code owner July 31, 2026 13:50
@sydorovdmytro
sydorovdmytro merged commit 65d5e6a into main Jul 31, 2026
5 checks passed
@sydorovdmytro
sydorovdmytro deleted the devops-1238/anchor-heal-classify-exports branch July 31, 2026 13:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant