Re-vendor the contract at Forgejo 16.0.3 #5

Merged

stephen merged 1 commit from chore/revendor-forgejo-16.0.3 into main

2026-09-11 04:16:33 +00:00

stephen commented

2026-09-11 03:50:28 +00:00

Owner

rasterhub.com now runs 16.0.3+gitea-1.22.0; the vendored spec was pinned at 15.0.2. This is make fetch + make regenerate against the live swagger, nothing hand-written.

Twelve paths are new, no path or schema was removed, and no schema gained a required field. The six that matter to a client are the Actions endpoints Forgejo 15 has no answer for:

GET  /repos/{owner}/{repo}/actions/runs/{run_id}/jobs
GET  /repos/{owner}/{repo}/actions/jobs/{job_id}/logs
GET  /repos/{owner}/{repo}/actions/runs/{run_id}/logs
POST /repos/{owner}/{repo}/actions/runs/{run_id}/cancel
GET  /repos/{owner}/{repo}/actions/artifacts (+ /{artifact_id}, /{artifact_id}/zip)
GET  /repos/{owner}/{repo}/actions/runs/{run_id}/artifacts

The rest are admin token management, an ActivityPub remote-follow, and a global run list. Two new schemas: ActionArtifact and APRemoteFollowOption.

Per OPERATIONS.md this is the low-risk shape of a re-vendor: new endpoints reach neither consumer until its generator filter opts in, so nothing here changes generated code on its own.

versionFloor stays at 7.0.0. 16.0.3 is a capability ceiling to detect at runtime, not a new floor, because both the LTS (15) and stable (16) lines stay supported.

The one field that goes the other way

EditPullRequestOption.draft disappears. It was added to the vendored spec by hand in #3, and a faithful re-fetch drops it.

This is not an upstream regression. Forgejo carries no Draft field on EditPullRequestOption in either v15.0.2 or v16.0.3, and EditPullRequest in routers/api/v1/repo/pull.go reads no such field in either tag. The property described a request field the server has never parsed, so restoring it would re-vendor a fiction. The patches/ overlay step that would have made the hand-edit durable across a re-fetch was never wired into the Makefile, which is why #3 vanished silently here rather than conflicting.

Both consumers send draft: false to mark a pull request ready (fj pr ready, Fjord's PullRequestDetailView.markReady). That path is tracked separately. It does not block this re-vendor: neither consumer's generated code moves until it bumps this submodule pointer.

This pull request is deliberately open as a draft, as the live-server test for exactly that question.

rasterhub.com now runs `16.0.3+gitea-1.22.0`; the vendored spec was pinned at `15.0.2`. This is `make fetch` + `make regenerate` against the live swagger, nothing hand-written. Twelve paths are new, no path or schema was removed, and no schema gained a required field. The six that matter to a client are the Actions endpoints Forgejo 15 has no answer for: ``` GET /repos/{owner}/{repo}/actions/runs/{run_id}/jobs GET /repos/{owner}/{repo}/actions/jobs/{job_id}/logs GET /repos/{owner}/{repo}/actions/runs/{run_id}/logs POST /repos/{owner}/{repo}/actions/runs/{run_id}/cancel GET /repos/{owner}/{repo}/actions/artifacts (+ /{artifact_id}, /{artifact_id}/zip) GET /repos/{owner}/{repo}/actions/runs/{run_id}/artifacts ``` The rest are admin token management, an ActivityPub remote-follow, and a global run list. Two new schemas: `ActionArtifact` and `APRemoteFollowOption`. Per OPERATIONS.md this is the low-risk shape of a re-vendor: new endpoints reach neither consumer until its generator filter opts in, so nothing here changes generated code on its own. `versionFloor` stays at `7.0.0`. 16.0.3 is a capability ceiling to detect at runtime, not a new floor, because both the LTS (15) and stable (16) lines stay supported. ### The one field that goes the other way `EditPullRequestOption.draft` disappears. It was added to the vendored spec by hand in #3, and a faithful re-fetch drops it. This is not an upstream regression. Forgejo carries no `Draft` field on `EditPullRequestOption` in either `v15.0.2` or `v16.0.3`, and `EditPullRequest` in `routers/api/v1/repo/pull.go` reads no such field in either tag. The property described a request field the server has never parsed, so restoring it would re-vendor a fiction. The `patches/` overlay step that would have made the hand-edit durable across a re-fetch was never wired into the Makefile, which is why #3 vanished silently here rather than conflicting. Both consumers send `draft: false` to mark a pull request ready (`fj pr ready`, Fjord's `PullRequestDetailView.markReady`). That path is tracked separately. It does not block this re-vendor: neither consumer's generated code moves until it bumps this submodule pointer. This pull request is deliberately open as a draft, as the live-server test for exactly that question.

stephen added 1 commit

2026-09-11 03:50:28 +00:00

Re-vendor the contract at Forgejo 16.0.3

CI / Contract drift (pull_request) Successful in 11s

Details

786dc4a2b4

rasterhub.com now runs 16.0.3+gitea-1.22.0; the vendored spec was pinned at
15.0.2. Re-runs `make fetch` and `make regenerate` against the live swagger.

Twelve paths are new, no path or schema was removed, and no schema gained a
required field, so the spec is additive for both consumers. The six that
matter to a client are the Actions ones Forgejo 15 has no answer for:

    GET  /repos/{owner}/{repo}/actions/runs/{run_id}/jobs
    GET  /repos/{owner}/{repo}/actions/jobs/{job_id}/logs
    GET  /repos/{owner}/{repo}/actions/runs/{run_id}/logs
    POST /repos/{owner}/{repo}/actions/runs/{run_id}/cancel
    GET  /repos/{owner}/{repo}/actions/artifacts (+ /{artifact_id}, /zip)
    GET  /repos/{owner}/{repo}/actions/runs/{run_id}/artifacts

The rest are admin token management, an ActivityPub remote-follow, and a
global run list. Two new schemas: ActionArtifact, APRemoteFollowOption.

New endpoints reach neither consumer until its generator filter opts in, so
nothing here changes generated code on its own. `versionFloor` stays at
7.0.0: 16.0.3 is a capability ceiling to detect at runtime, not a new floor,
because both the LTS (15) and stable (16) lines are supported.

One field goes the other way. `EditPullRequestOption.draft` was added to the
vendored spec by hand in #3 on the belief that it mirrored upstream, and a
faithful re-fetch drops it. It is not an upstream regression: Forgejo carries
no Draft field on that struct in either v15.0.2 or v16.0.3, and
EditPullRequest reads no such field in either tag, so the property described
a request field the server has never parsed. Restoring it would re-vendor a
fiction, and the patches/ overlay step that would have made the hand-edit
durable was never wired into the Makefile, which is why #3 vanished silently
here. Both consumers send `draft: false` to mark a pull request ready
(fj pr ready, Fjord's PullRequestDetailView); that path is tracked separately
and does not block this re-vendor, since neither consumer's generated code
moves until it bumps this pointer.

stephen changed title from ~~Re-vendor the contract at Forgejo 16.0.3~~ to WIP: Re-vendor the contract at Forgejo 16.0.3

2026-09-11 03:50:37 +00:00

stephen changed title from ~~WIP: Re-vendor the contract at Forgejo 16.0.3~~ to Re-vendor the contract at Forgejo 16.0.3

2026-09-11 03:50:47 +00:00

stephen merged commit 36040321e3 into main

2026-09-11 04:16:33 +00:00

stephen deleted branch chore/revendor-forgejo-16.0.3

2026-09-11 04:16:33 +00:00

stephen referenced this pull request from a commit

2026-09-11 04:16:34 +00:00

Re-vendor the contract at Forgejo 16.0.3 (#5)