Guides

Details

Category: Guides

• Applicable Software: MokoGIT
• Min Version Number: 02.00.00
• Max Version Number: Not Applicable

MokoGIT extends the built-in issue tracker with organization-level custom issue metadata — Statuses, Priorities, and Types that every repository in the org shares. Unlike plain labels, these are first-class fields with their own definitions, colors, defaults, and (optionally) required-on-create enforcement.

Custom Statuses

• Each org defines its own issue statuses (for example In Progress, Blocked, Pending: Review, Resolved), each with a color and a closes-issue flag — applying a closes-issue status closes the issue.
• Presets seed a standard status set into an org in one step, and a protected baseline keeps core statuses from being removed.

Priorities

• Org-defined priorities (for example Critical / High / Medium / Low), each with a color; one is marked the default applied to new issues.

Types

• Org-defined issue types (for example Bug, Feature, Enhancement, Task, Documentation, Security, Infrastructure), each with a color; one is the default.

Required on create

An organization can require that every new issue carry a Status, Priority, and Type. When enforced, creating an issue without them is rejected — so issues are triaged consistently across the org's repositories from the moment they're opened.

Where to set it

• Org-wide: organization Settings → Issue Statuses / Priorities / Types. The same definitions are available over the REST API (and the MokoGIT MCP server) for automation.
• Per issue: choose the Status, Priority, and Type when creating or editing an issue.

Get help

Open a support ticket or call (931) 820-0265.

Last Updated: October 06, 2026

Hits: 30

• mokogit

Details

Category: Guides

• Applicable Software: MokoGIT
• Min Version Number: 02.13.00
• Max Version Number: Not Applicable

Overview

MokoGIT's built-in update server turns a repository's releases into a live update feed. With selectable feed formats, the feed format is chosen per repository, so the update server can speak the right protocol for each kind of software — a Joomla-style updates.xml for extensions, or an electron-updater latest.yml for desktop apps. See also MokoGIT: Releases & the Update Server.

Choosing a format

Each repository has an Update Feed Format setting (repository Settings → Update Server, or the update_feed_format field on the repo metadata REST API):

Format	Serves	For
off	nothing (disabled)	—
joomla-xml	Joomla updates.xml (one signed package per stream)	Joomla extensions; recipe & manifest catalogs
electron-yml	electron-updater latest.yml / latest-linux.yml / latest-mac.yml	Electron desktop apps (self-update)

How the default is chosen

When the setting is left unset, MokoGIT derives the format from the repository's platform (an electron repo defaults to electron-yml; a joomla repo to joomla-xml; everything else is off). Setting the field explicitly always overrides the platform default.

Endpoints

• Joomla: .../{owner}/{repo}/updates.xml
• Electron: .../{owner}/{repo}/updates/electron/{channel}/latest.yml

Every feed is channel-aware (dev / rc / stable) and signed, so a client only ever sees updates for the channel it follows.

Roadmap

The generator is designed so new formats are cheap to add. Planned generators give every platform a feed its own tooling understands: a Composer packages.json repository (composer require), a Go module proxy (go get), a private npm registry (npm install), a Sparkle appcast, and AppImage .zsync delta updates.

Get help

Open a support ticket or call (931) 820-0265.

Last Updated: October 06, 2026

Hits: 36

• mokogit
• ci/cd

Details

Category: Guides

• Applicable Software: MokoGIT
• Min Version Number: 02.09.00
• Max Version Number: Not Applicable

What cascade merge rules do

When a fix lands on a higher channel (for example a hotfix merged into stable), lower channels like dev need that change too, or they will silently drift behind. Cascade merge rules keep your branches in sync automatically by propagating merges from a source branch into a target branch — typically back down the ladder, such as stable → dev.

Native, not a workflow

Cascade is a native MokoGIT feature handled by the forge itself. It replaced the old cascade.yml / cascade-dev.yml Actions workflow that used to run on a runner. Because it is built in, cascading:

• needs no runner, no workflow file in your repository, and no CI minutes;
• does not depend on Sync Profiles distributing a workflow to keep it working;
• is configured as data (rules) on the repository rather than as YAML you maintain.

How a rule is defined

Each cascade rule maps a source branch to a target branch and has:

• Enabled — whether the rule is active.
• Mode — how conflicts are handled: notify (open a notification / let a human resolve) or auto_resolve (attempt to resolve automatically).
• Auto-merge — whether the cascaded merge is completed automatically when it applies cleanly.

A repository also has a cascade default mode (for example notify) used when a rule does not override it. A typical channel-named repository runs a single rule: stable → dev, so hotfixes shipped on stable flow back into dev. Repositories on the conventional model use the equivalent main → dev rule.

How it differs from the old cascade.yml

	Old cascade.yml workflow	Native cascade rules
Where it runs	On a runner, as an Actions job	Inside the forge, no runner
Configuration	A YAML file synced into each repo	Data rules on the repository
Upkeep	Kept current by Sync Profiles	Nothing to sync or maintain
Conflict handling	Job succeeds/fails	notify or auto_resolve per rule

The cascade.yml workflow has been retired across the fleet in favor of these native rules.

Related

See MokoGIT: Branch Model & Release Channels for the branch ladder cascade keeps in sync, and MokoGIT: CI/CD & Release Pipeline for how promotion up the ladder works.

Get help

Open a support ticket or call (931) 820-0265.

Last Updated: October 06, 2026

Hits: 39

• mokogit
• ci/cd

Details

Category: Guides

• Applicable Software: MokoGIT
• Min Version Number: 02.09.00
• Max Version Number: Not Applicable

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) 820-0265.

Last Updated: October 06, 2026

Hits: 41

• mokogit
• ci/cd