MokoGIT: CI/CD & Release Pipeline

Overview

MokoGIT's own repositories share a common CI/CD pipeline, distributed automatically to every repository by Sync Profiles. Rather than hand-maintaining workflows per repo, each repository receives the same small set of platform workflows that build, test, deploy, and release along the dev → rc → stable ladder. You never have to wire this up yourself.

The core workflows

deploy.yml — one tier-selecting deploy

A single deploy.yml handles deployment for every environment and picks the right tier from the branch or event that triggered it:

• push to dev → build and deploy to the development environment.
• pull request into stable or rc → build and deploy to the release-candidate environment for testing.
• push to stable → build and deploy to production.

Because one workflow selects the tier, there are no separate deploy-dev, deploy-rc, and deploy-prod files to keep in sync — the branch is the switch.

auto-release.yml — universal stable releases

A universal auto-release.yml cuts the stable release when content lands on the production branch: it tags the version, publishes the release with notes, and attaches build artifacts. Downstream, the update server can advertise that release to installed software (see MokoGIT: Releases & the Update Server).

pre-release.yml — the development channel

A pre-release.yml publishes development-channel builds so pre-stable versions are available for testing without being presented as certified stable releases.

Version bumping

Version numbers advance automatically on every repository — including ones with releases turned off — while the actual publishing of a release is gated on whether releases are enabled. This means templates and internal repos keep a correct, advancing version without ever cutting a public release. The canonical version lives in the repository's Makefile and is stamped into every manifest in a single commit.

Heavy suite vs. light per-PR checks

To keep everyday pull requests fast while still guarding release branches, the pipeline runs two levels of testing:

• Light per-PR CI — runs on every pull request: quick build, lint, and a fast subset of checks so contributors get feedback in minutes.
• Gated heavy suite — the full, slower test suite (for example, the complete Go integration suite) runs on the release branches (rc / stable) rather than on every PR. This gates promotion up the ladder without slowing down day-to-day work.

How it ties together

Feature and fix branches open PRs into dev, where light CI runs. Content is promoted dev → rc (heavy suite runs, RC deploy for testing), then rc → stable, where auto-release.yml cuts the stable release and deploy.yml ships production. Development-channel builds come from pre-release.yml along the way.

Managed runners

Moko Consulting operates and scales the Gitea Actions runner fleet that executes these workflows. If you need custom runners or a specialized build environment, contact our support team.

The fleet includes a dedicated priority runner for release-critical work. Release workflows target runners conditionally: by default they use the shared runner pool, but a repository can opt into the priority runner so its releases jump ahead of the shared queue — useful for the tools that other releases depend on.

Stuck-job detection. Three background janitors keep the queue healthy: a running job whose runner has gone silent is stopped (a “zombie”), a job that never finishes is stopped after a few hours, and a job that no runner ever picks up is cancelled (“abandoned”).

Cross-repo Actions queue

A single pane shows the Actions queue — waiting, running, and blocked jobs — across many repositories at once, so a backed-up runner or a stuck deploy is obvious at a glance. Site administrators see the whole instance (Site Administration → Actions → Queue); organization members see the queue scoped to their organization's repositories. You can filter by status, by trigger event, and by free-text search across repository, workflow, and job name. Jobs that have crossed the stuck thresholds are highlighted at the top of the list — surfacing a pileup before the background janitors step in.

Related

See MokoGIT: Branch Model & Release Channels for the branch ladder, CI/CD with Gitea Actions for authoring your own workflows, MokoGIT: Sync Profiles for how these workflows are distributed, and MokoGIT: Releases & the Update Server for the release side.

Get help

Open a support ticket or call (931) 279-6313.