mirror of
https://github.com/RayLabsHQ/gitea-mirror.git
synced 2026-06-28 05:50:58 +02:00
ARUNAVO RAY
1d9dfdeb70
Release assets were uploaded only on the create path of mirrorGitHubReleasesToGitea(). When a Gitea release already existed, the update path PATCHed the changelog/title and `continue`d without ever touching assets. So any release whose assets were not fully uploaded on that single create-path run — first sync interrupted, a transient download/upload failure, large multi-MB assets, etc. — stayed permanently asset-less, and re-syncing always hit the update path and could never recover it. Asset failures were also swallowed to console.error, so the job still reported success (the "no errors in the logs" in #331). Reproduced on a real Forgejo pull-mirror with shauninman/MinUI: a GitHub release with two ~35-40MB binaries became a Gitea release with 0 assets (just Forgejo's auto-generated source archive), and re-syncing left it at 0 while logging "Updating existing release". Fix: - Add reconcileReleaseAssets(), an idempotent reconciler run on BOTH the create and update paths. It compares Gitea's existing attachments to GitHub's by name+size: skips matches, uploads missing ones, replaces size-mismatched copies. Existing broken releases self-heal on next sync. - Extract the pure decision into classifyAssetsForReconciliation() for unit testing (the absence of asset tests is why this slipped past #310). - Surface asset upload counts in the summary and emit a visible warning when any fail, instead of silently swallowing them. - Add 5 unit tests covering the broken state, partial backfill, idempotency, size-mismatch replacement, and the no-assets case. Verified end-to-end against the real function on a Forgejo pull-mirror: 0 -> 2 assets backfilled, already-present assets skipped (no re-download), second run uploads 0.