test: live-forge probe for `repo protect set` idempotency on slash-bearing pattern rules #397

New issue

Open

opened 2026-08-17 08:21:57 +00:00 by hexajon · 0 comments

hexajon commented

2026-08-17 08:21:57 +00:00

Owner

Follow-up from #375 (the set create-or-update upsert).

Gap

set decides create-vs-update from a GET probe of the existing rule. #375 fixed a real bug where the branch-protection by-name client paths concatenated the rule name raw, so a slash-bearing pattern rule like release/* never matched the single-segment route: the probe 404d and set always re-created, breaking idempotency. The fix url.PathEscapes the name in the get/update/delete client methods.

The fix is verified by unit tests (TestProtectSetCmdEscapesPatternName pins the escaped wire path) and matches both the upstream Gitea SDK and the in-repo wiki-client precedent (client_wiki.go, legacy tracker 1203). The one link not machine-verified is the live forge's server-side routing of a %2F-encoded slash as a single {name} path segment. We have strong indirect evidence (the wiki client sends encoded slash-bearing segments against the live forge daily), so this is verification-completeness, not a suspected regression.

Ask

Add a live-forge conformance probe: against a live Gitea/Forgejo, run repo protect set release/* twice and assert the second run takes the UPDATE path (a 200 PATCH), not a duplicate-create error. This closes the last unverified link for pattern-rule idempotency.

Related: #375.

Follow-up from #375 (the `set` create-or-update upsert). ## Gap `set` decides create-vs-update from a GET probe of the existing rule. #375 fixed a real bug where the branch-protection by-name client paths concatenated the rule name raw, so a slash-bearing pattern rule like `release/*` never matched the single-segment route: the probe 404d and `set` always re-created, breaking idempotency. The fix `url.PathEscape`s the name in the get/update/delete client methods. The fix is verified by unit tests (`TestProtectSetCmdEscapesPatternName` pins the escaped wire path) and matches both the upstream Gitea SDK and the in-repo wiki-client precedent (`client_wiki.go`, legacy tracker 1203). The one link not machine-verified is the live forge's server-side routing of a `%2F`-encoded slash as a single `{name}` path segment. We have strong indirect evidence (the wiki client sends encoded slash-bearing segments against the live forge daily), so this is verification-completeness, not a suspected regression. ## Ask Add a live-forge conformance probe: against a live Gitea/Forgejo, run `repo protect set release/*` twice and assert the second run takes the UPDATE path (a 200 PATCH), not a duplicate-create error. This closes the last unverified link for pattern-rule idempotency. Related: #375.

hexajon added the

status/needs-verification

testing

labels

2026-08-17 08:21:57 +00:00

hexajon referenced this issue

2026-08-17 08:25:20 +00:00

feat(repo): add branch-protection set (create-or-update upsert) #400