The Branch Protection Setup workflow applies standardised branch protection rules to all governed repositories in the MokoConsulting organization. It runs from the moko-platform repository and uses the Gitea 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 moko-platform, 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`	Gitea instance URL
`GITEA_ORG`	`MokoConsulting`	Organization name

Secrets

Secret	Required	Description
`GA_TOKEN`	Yes	Gitea 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
`moko-platform`	Standards repository
`moko-platform`	Standards repository
`MokoTesting`	Testing infrastructure
`moko-platform-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 Gitea 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: moko-platform · moko-platform 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

Branch Protection Setup Workflow

Table of Contents

Overview