mirror of
https://github.com/RayLabsHQ/gitea-mirror.git
synced 2026-10-25 08:01:12 +00:00
ARUNAVO RAY
187ecc5d60
* fix(releases): send Gitea release title as `name`, not `title` (#334) Gitea/Forgejo expose the release title through the JSON field `name` (the API Go struct is `Title string `+"`"+`json:"name"`+"`"+`). The release create and update payloads sent `title:` instead, which Gitea silently ignores, so every mirrored release landed with a blank title. Verified live against Gitea 1.24.7: a POST/PATCH with `title` yields `name: ""`; the same call with `name` sets the title correctly. The update path also self-heals previously-mirrored releases whose names were left blank, since the existing-vs-expected name comparison already drives a PATCH. Adds gita-release-name.test.ts, which drives the real mirrorGitHubReleasesToGitea create/update paths with a mocked fetch and asserts the payload carries `name` (and never `title`). * fix(issues): reconcile labels on issue/PR update via the labels sub-resource (#334 sibling) Gitea/Forgejo's `EditIssueOption` has no `labels` field (only `CreateIssueOption` does), so a `labels` key in a `PATCH .../issues/{index}` body is silently dropped — the same silent-ignore class as the release `title` vs `name` bug. The issue and PR-as-issue update paths sent `labels` in the PATCH body, so label changes never propagated onto already-mirrored issues (and a deadlock-orphaned issue recovered via PATCH never got its labels). Fix: add `reconcileGiteaIssueLabels`, which replaces the label set via `PUT .../issues/{index}/labels` (idempotent — adds new, removes deleted). Call it on the two issue update paths and the two PR-issue update paths, and drop the dead `labels` key from those PATCH bodies. Labels on freshly created issues still come from CreateIssueOption on the POST. Verified live against Gitea 1.24.7 (PATCH ignores labels; PUT applies them) and end-to-end (a drifted mirrored issue reconciled from no-labels to its GitHub label set). Adds gitea-issue-labels.test.ts driving the real mirrorGitRepoIssuesToGitea update path; the test carries a self-contained http-client mock so it is immune to another suite's global module mock. * test: make #334 regression tests deterministic via pure payload builders The prior tests drove the real mirror functions with a global `fetch` mock. That is order/version-fragile: another suite installs a process-global `mock.module("@/lib/http-client")`, and bun 1.3.13 (CI) runs test files concurrently, so `globalThis.fetch` races across files and `isRepoPresentInGitea` (raw fetch) intermittently sees the wrong mock — green locally on bun 1.3.6, red in CI. Extract the payload construction into pure, exported builders and assert on those instead (the repo's existing `classify*` pattern): buildGiteaReleasePayload (create+update send `name`, never `title`), buildGiteaIssueEditPayload (edit body never carries `labels`), buildGiteaIssueLabelsPayload (labels sub-resource body). Behavior is unchanged — the builders return the exact same objects the call sites built inline — and the fixes remain verified live on Gitea 1.24.7.