mirror of
https://github.com/go-gitea/gitea.git
synced 2026-07-03 08:03:34 +00:00
458c11bd68
Fixes #38278 ## Problem When branch protection matches the branch an Actions workflow pushes to, the runner's `git push` is rejected — even though the workflow token has `contents: write` and the same push performed with a PAT (write access) succeeds. Disabling protection or changing the pattern so it no longer matches makes the push work. ## Root cause In `preReceiveBranch` (`routers/private/hook_pre_receive.go`), the "can the doer push to this protected branch" check resolves the pusher with `user_model.GetUserByID(ctx, ctx.opts.UserID)`. For an Actions push the user ID is `-2` (the virtual `ActionsUserID`), which has no database row, so the lookup fails. Even past that, `CanUserPush` → `HasAccessUnit`/whitelist membership cannot evaluate a virtual user and returns `false`. As a result the Actions bot was rejected on every matching protected branch, despite the earlier `assertCanWriteRef` already confirming the token's code-write via `GetActionsUserRepoPermission`. This was inconsistent: a PAT with identical write access passed the exact same check. ## Fix Evaluate the Actions bot against its already-computed token permission instead of a user lookup, mirroring the existing `IsUserMergeWhitelisted` pattern: - Add `CanActionsUserPush` / `CanActionsUserForcePush` on `ProtectedBranch`, which take the precomputed `access_model.Permission`. - Allow the push when push is enabled, **no** push whitelist is enforced, and the token has code-write. - Keep the bot blocked when a whitelist is enforced — it cannot be added to one, so it must use a pull request. This preserves the whitelist as a real security boundary. Force-push, signed-commit and protected-file-path checks are untouched. --------- Signed-off-by: bircni <bircni@icloud.com> Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>