MokoConsulting/MokoGitea-Fork
1
0
Fork 0
Code Issues 135 Pull Requests Releases 96 Wiki Activity

Add a dedicated system API/automation bot account (mokogitea-api) #747

New Issue
Open
opened 2026-07-05 21:23:49 +00:00 by jmiller · 2 comments
jmiller commented 2026-07-05 21:23:49 +00:00
Owner
Copy Link
Copy Source

Add a second system bot account for API/automation, distinct from the Actions runner bot — so automation (MCP server, scripts, integrations) acts as a first-class identity that can be allowlisted in branch protection with its own toggle.

Background

Today there is exactly one system bot: the Actions user mokogitea-actions (id -2, models/user/user_system.go), allow-listed in branch protection via the whitelist_actions_user toggle. There is no separate API bot. Requested so an "API bot" can be treated the same way (a fixed system identity + toggle), not just a normal user account.

Proposed implementation

  • New system user parallel to the Actions user: e.g. mokogitea-api, reserved negative id (e.g. -3), email mokogitea-api[bot]@mokoconsulting.tech, FullName "MokoGitea API". Add constructor + IsAPIBot()/system-user handling in models/user/user_system.go and reserve the name (models/user/user.go reserved list).
  • Branch-protection toggle for it at repo AND org level: whitelist_api_user (+ merge/force-push/delete variants), mirroring whitelist_actions_user. Enforcement in models/git/protected_branch.go (user.IsAPIBot() && WhitelistAPIUser).
  • Merge logic: include it in mergeMostRestrictive (org-level branch protection) the same way as the actions-user flag.
  • UI: a checkbox next to "Allow actions bot" in the repo + org branch-protection forms.
  • Auto-membership: optionally auto-add it (and/or the actions bot) to the CI/CD or Bots team on org creation — see #746 / #745.
  • Email-domain exemption: like the actions bot, the API bot must be exempt from the org email-domain policy (#732) when auto-added (see #746).

Open questions

  • Should the API bot own the token the mokogitea-mcp server uses (currently a crash-looping container needing config)?
  • Backfill: create the system user via migration/seed so existing instances get it.

Related: #745 §2 (bots naming), #746 (auto-add bot to team), #732 (email-domain policy), #727 (org-governance). Pairs with the in-progress org-level branch-protection user/email allowlist + actions-bot toggle.

https://claude.ai/code/session_01Wsno14cxE49MstXFs9G5KT

Add a second **system bot** account for API/automation, distinct from the Actions runner bot — so automation (MCP server, scripts, integrations) acts as a first-class identity that can be allowlisted in branch protection with its own toggle. ## Background Today there is exactly one system bot: the **Actions** user `mokogitea-actions` (id `-2`, `models/user/user_system.go`), allow-listed in branch protection via the `whitelist_actions_user` toggle. There is **no** separate API bot. Requested so an "API bot" can be treated the same way (a fixed system identity + toggle), not just a normal user account. ## Proposed implementation - **New system user** parallel to the Actions user: e.g. `mokogitea-api`, reserved negative id (e.g. `-3`), email `mokogitea-api[bot]@mokoconsulting.tech`, FullName "MokoGitea API". Add constructor + `IsAPIBot()`/system-user handling in `models/user/user_system.go` and reserve the name (`models/user/user.go` reserved list). - **Branch-protection toggle** for it at **repo AND org** level: `whitelist_api_user` (+ merge/force-push/delete variants), mirroring `whitelist_actions_user`. Enforcement in `models/git/protected_branch.go` (`user.IsAPIBot() && WhitelistAPIUser`). - **Merge logic**: include it in `mergeMostRestrictive` (org-level branch protection) the same way as the actions-user flag. - **UI**: a checkbox next to "Allow actions bot" in the repo + org branch-protection forms. - **Auto-membership**: optionally auto-add it (and/or the actions bot) to the CI/CD or **Bots** team on org creation — see #746 / #745. - **Email-domain exemption**: like the actions bot, the API bot must be exempt from the org email-domain policy (#732) when auto-added (see #746). ## Open questions - Should the API bot own the token the **mokogitea-mcp** server uses (currently a crash-looping container needing config)? - Backfill: create the system user via migration/seed so existing instances get it. Related: #745 §2 (bots naming), #746 (auto-add bot to team), #732 (email-domain policy), #727 (org-governance). Pairs with the in-progress org-level branch-protection user/email allowlist + actions-bot toggle. https://claude.ai/code/session_01Wsno14cxE49MstXFs9G5KT
jmiller commented 2026-07-05 21:23:52 +00:00
Author
Owner
Copy Link
Copy Source

Branch created: feature/747-add-a-dedicated-system-api-automation-bo

git fetch origin
git checkout feature/747-add-a-dedicated-system-api-automation-bo
Branch created: [`feature/747-add-a-dedicated-system-api-automation-bo`](https://git.mokoconsulting.tech/MokoConsulting/MokoGitea-Fork/src/branch/feature/747-add-a-dedicated-system-api-automation-bo) ```bash git fetch origin git checkout feature/747-add-a-dedicated-system-api-automation-bo ```
jmiller commented 2026-07-05 21:29:41 +00:00
Author
Owner
Copy Link
Copy Source

Implementation reference — mirror the actions_user toggle

The API-bot toggle is a near-exact parallel of the existing whitelist_actions_user mechanism. The org-level actions-user allowlist + toggle is being built now (lands via #733); replicate every touchpoint below with api / APIUser / IsAPIBot instead of actions / ActionsUser / IsActions.

System user (the one genuinely new piece):

  • models/user/user_system.go: define APIUserID int64 = -3, APIUserName = "mokogitea-api", APIUserEmail, NewAPIUser() + IsAPIBot() — parallel to ActionsUserID = -2 / ActionsUserName = "mokogitea-actions" / NewActionsUser() / IsActions().
  • models/user/user.go: add mokogitea-api to the reserved-name list (next to mokogitea-actions, ~line 634).

Repo-level branch protection:

  • models/git/protected_branch.go: add WhitelistAPIUser, MergeWhitelistAPIUser, ForcePushAllowlistAPIUser, DeleteAllowlistAPIUser bool (parallel to *ActionsUser). Enforcement: in IsUserPushWhitelisted / IsUserMergeWhitelisted add user.IsAPIBot() && protectBranch.WhitelistAPIUser next to the existing user.IsActions() && …WhitelistActionsUser checks (~lines 137 / 246).
  • modules/structs/repo_branch.go: add push_whitelist_api_user (+ merge/force-push/delete) to Create/Edit/response options.
  • Repo web form: add an "Allow API bot" checkbox next to the actions-bot one in templates/repo/settings/protected_branch.tmpl.

Org-level branch protection (copy the actions-user work landing in #733):

  • models/git/org_protected_branch.go: add WhitelistAPIUser etc. + ToProtectedBranch() mapping.
  • modules/structs/org_branch.go: add push_whitelist_api_user etc. to Create/Edit/response.
  • routers/api/v1/org/branch_protection.go: set/render the api-user bools (copy the actions-user handling).
  • models/git/protected_branch_merge.go: add mergeAllowFlag(...) lines for the 4 api-user fields — reuse the same mergeAllowFlag helper introduced for actions-user.

Migration: add the *_api_user columns to both protected_branch and org_protected_branch tables (next free migration number at implementation time).

Swagger regen + tests: extend the protected_branch_merge test with api-user cases.

Net: it's the whitelist_actions_user pattern (proven across repo + org via #733) plus the mokogitea-api system user. Diff the org-actions-user commits from #733 for the exact shape to copy.

https://claude.ai/code/session_01Wsno14cxE49MstXFs9G5KT

### Implementation reference — mirror the `actions_user` toggle The API-bot toggle is a **near-exact parallel** of the existing `whitelist_actions_user` mechanism. The org-level actions-user allowlist + toggle is being built now (lands via #733); replicate every touchpoint below with `api` / `APIUser` / `IsAPIBot` instead of `actions` / `ActionsUser` / `IsActions`. **System user** (the one genuinely new piece): - `models/user/user_system.go`: define `APIUserID int64 = -3`, `APIUserName = "mokogitea-api"`, `APIUserEmail`, `NewAPIUser()` + `IsAPIBot()` — parallel to `ActionsUserID = -2` / `ActionsUserName = "mokogitea-actions"` / `NewActionsUser()` / `IsActions()`. - `models/user/user.go`: add `mokogitea-api` to the reserved-name list (next to `mokogitea-actions`, ~line 634). **Repo-level branch protection:** - `models/git/protected_branch.go`: add `WhitelistAPIUser`, `MergeWhitelistAPIUser`, `ForcePushAllowlistAPIUser`, `DeleteAllowlistAPIUser bool` (parallel to `*ActionsUser`). Enforcement: in `IsUserPushWhitelisted` / `IsUserMergeWhitelisted` add `user.IsAPIBot() && protectBranch.WhitelistAPIUser` next to the existing `user.IsActions() && …WhitelistActionsUser` checks (~lines 137 / 246). - `modules/structs/repo_branch.go`: add `push_whitelist_api_user` (+ merge/force-push/delete) to Create/Edit/response options. - Repo web form: add an "Allow API bot" checkbox next to the actions-bot one in `templates/repo/settings/protected_branch.tmpl`. **Org-level branch protection** (copy the actions-user work landing in #733): - `models/git/org_protected_branch.go`: add `WhitelistAPIUser` etc. + `ToProtectedBranch()` mapping. - `modules/structs/org_branch.go`: add `push_whitelist_api_user` etc. to Create/Edit/response. - `routers/api/v1/org/branch_protection.go`: set/render the api-user bools (copy the actions-user handling). - `models/git/protected_branch_merge.go`: add `mergeAllowFlag(...)` lines for the 4 api-user fields — **reuse the same `mergeAllowFlag` helper** introduced for actions-user. **Migration:** add the `*_api_user` columns to **both** `protected_branch` and `org_protected_branch` tables (next free migration number at implementation time). **Swagger regen + tests:** extend the `protected_branch_merge` test with api-user cases. Net: it's the `whitelist_actions_user` pattern (proven across repo + org via #733) **plus** the `mokogitea-api` system user. Diff the org-actions-user commits from #733 for the exact shape to copy. https://claude.ai/code/session_01Wsno14cxE49MstXFs9G5KT
Sign in to join this conversation.
Labels
Clear labels
breaking-change
Breaking API or behavior change
 ci-cd
CI/CD pipeline changes
 config
Configuration changes
 dependencies
Dependency updates
 deploy-failure
Deployment failed
 docker
Docker/container changes
 documentation
Documentation changes
 feature: wiki
Wiki system enhancements
 good first issue
Good for newcomers
 health-check
Repo health check result
 help wanted
Extra attention needed
 mokostandards
Related to MokoStandards framework
 push-failure
Git push operation failed
 security
Security vulnerability or hardening
 size/l
200-500 lines changed
 size/m
50-200 lines changed
 size/s
10-50 lines changed
 size/xl
500+ lines changed
 size/xs
< 10 lines changed
 standards-drift
Deviates from MokoStandards
 standards-update
MokoStandards compliance update
 sync-failure
Sync or mirror failed
 tech-debt
Technical debt and TODO/FIXME items
 upstream
upstream
Inherited from upstream Gitea
 work-in-progress
Draft or incomplete work
bug
Something is not working
 duplicate
This issue or pull request already exists
 enhancement
New feature
 help wanted
Need some help
 invalid
Something is wrong
 question
More information is needed
 wontfix
This won't be fixed
No labels
Priority Medium
Type Feature
Milestone
No items
No Milestone
Assignees
Clear assignees
jmiller (Jonathan Miller) moko-deploy (Moko Deploy Bot)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: MokoConsulting/MokoGitea-Fork#747
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?