The Branch Protection Setup workflow applies standardised branch protection rules to all governed repositories in the MokoConsulting organization. It runs from the mokocli repository and uses the MokoGitea API to create or update protection rules across repos.

Purpose

Consistency: Uniform branch protection across all repositories
Drift Prevention: Weekly scheduled runs enforce rules even if manually changed
Centralised Management: Single workflow controls protection for the entire organization
Override Authority: jmiller has full override capability on all branches

Key Features

✅ Idempotent: Deletes and recreates rules to avoid update conflicts
✅ Weekly Enforcement: Scheduled every Monday at 02:00 UTC
✅ Manual Dispatch: Target specific repos or run against all
✅ Dry Run Mode: Preview changes without applying
✅ Centralised: Lives in mokocli, applies to all governed repos

Protection Rules

Rule Summary

Branch	Push	Push Whitelist	Force Push	Force Push Whitelist	Block Rejected Reviews	Priority
`main`	Whitelist	jmiller	Whitelist	jmiller	Yes	1
`dev`	Open	—	Whitelist	jmiller	No	2
`rc/*`	Open	—	Whitelist	jmiller	No	3
`beta/*`	Open	—	Whitelist	jmiller	No	4
`alpha/*`	Open	—	Whitelist	jmiller	No	5

Rule Details

`main` (Priority 1 — Strictest)

Push: Restricted to whitelist (jmiller only)
Force Push: Restricted to whitelist (jmiller only)
Block on Rejected Reviews: Yes — prevents merging PRs with rejected reviews
Dismiss Stale Approvals: Yes — new commits invalidate previous approvals
Required Approvals: 0 (solo developer workflow)

`dev` (Priority 2)

Push: Open to all collaborators
Force Push: Restricted to jmiller only
Block on Rejected Reviews: No
Purpose: Development integration branch — needs open push for cascade workflow and CI bots

`rc/`, `beta/`, `alpha/*` (Priority 3-5)

Push: Open to all collaborators
Force Push: Restricted to jmiller only
Block on Rejected Reviews: No
Purpose: Pre-release channels — CI workflows push version bumps and package builds directly

Override Authority

jmiller has full override authority across all branches:

Can push directly to main (bypassing PR requirement)
Can force-push to any branch when needed (emergency fixes, history cleanup)
Is the only user in force-push whitelists on all branches

This ensures the organization owner can always intervene in emergencies without being blocked by protection rules.

Workflow Triggers

Trigger	Condition
`schedule`	Every Monday at 02:00 UTC (drift enforcement)
`workflow_dispatch`	Manual — supports `dry_run` and `repos` inputs

Inputs

Input	Type	Default	Description
`dry_run`	boolean	`false`	Preview mode — logs what would change without applying
`repos`	string	`""` (all)	Comma-separated repo names to target (empty = all governed repos)

Configuration

Environment Variables

Variable	Value	Description
`GITEA_URL`	`https://git.mokoconsulting.tech`	MokoGitea instance URL
`GITEA_ORG`	`MokoConsulting`	Organization name

Secrets

Secret	Required	Description
`MOKOGITEA_TOKEN`	Yes	MokoGitea API token with admin/repo permissions

Excluded Repositories

The following repos are excluded from protection rule application:

Repository	Reason
`gitea-org-config`	Platform infrastructure
`org-profile`	Platform infrastructure
`gitea-private`	Platform infrastructure
`gitea-server-setup`	Platform infrastructure
`mokocli`	Standards repository
`mokocli`	Standards repository
`MokoTesting`	Testing infrastructure
`mokocli-Template-*`	Template repositories
`MokoDoliProjTemplate`	Template repository

Usage

Apply to All Repos

Trigger the workflow manually with default inputs (no dry run, all repos).

Apply to Specific Repos

repos: MokoOnyx,MokoJoomla,MokoJGDPC

Preview Mode

Set dry_run: true to see which rules would be applied without making changes.

API Approach

The workflow uses a delete-then-create strategy for each rule:

DELETE /repos/{owner}/{repo}/branch_protections/{rule_name} — remove existing rule (if any)
POST /repos/{owner}/{repo}/branch_protections — create fresh rule

This avoids HTTP 422 errors from conflicting updates to existing rules.

Troubleshooting

HTTP 422 on Rule Creation

Symptom: Rule fails to create with HTTP 422

Common Causes:

Username in whitelist doesn't exist as a MokoGitea user (e.g., bot accounts)
Rule name conflicts with an existing rule that wasn't deleted

Solution: Check the error message in logs — it usually specifies which user or field is invalid

Rules Not Applying to Specific Repo

Symptom: Repo not appearing in workflow output

Cause: Repo is in the exclude list

Solution: Check the EXCLUDE variable in the workflow and remove the repo if it should be governed

Protection Rules Reverted

Symptom: Rules changed back to previous state after manual edit

Cause: Weekly schedule re-applies standard rules every Monday

Solution: Modify the workflow's rule definitions to make permanent changes — manual edits will be overwritten

Changelog

Version	Date	Changes
01.00.00	2026-05-07	Initial release — 5 branch rules across all governed repos

Repo: mokocli · mokocli wiki

Field	Value
Minimum Version	04.07.00
Platform	all
Applies To	All repositories

Revision	Date	Author	Description
1.0	2026-05-08	Moko Consulting	Initial version

Pages

Branch Protection Setup Workflow

Table of Contents

Overview