You are here:

MokoGIT

MokoGIT is your private, fully managed Git hosting service powered by Gitea. Manage repositories, CI/CD pipelines, issues, and wiki documentation.

What are Gitea Actions?

Gitea Actions is MokoGIT's built-in CI/CD system. It uses a workflow syntax compatible with GitHub Actions, so if you've used GitHub Actions before, you'll feel right at home. Moko Consulting manages the runner infrastructure, so you can focus on writing your pipelines.

Creating Your First Workflow

In your repository, create the directory .mokogit/workflows/. (The legacy .gitea/workflows/ and .github/workflows/ paths are still recognized for compatibility.)
Add a YAML file (e.g., ci.yaml) with your workflow definition.
Commit and push — the workflow will run automatically.

Example: Basic CI Pipeline

name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install dependencies
        run: npm ci

      - name: Run tests
        run: npm test

Workflow Triggers

Control when workflows run using the on key:

push — Run on commits pushed to specified branches.
pull_request — Run when PRs are opened, updated, or synchronized.
schedule — Run on a cron schedule (e.g., nightly builds).
workflow_dispatch — Manually trigger from the MokoGIT UI.

Secrets and Variables

Store sensitive values (API keys, deployment credentials) as repository secrets:

Go to Settings → Actions → Secrets.
Click Add Secret.
Enter a Name and Value.

Reference secrets in your workflow:

steps:
  - name: Deploy
    run: ./deploy.sh
    env:
      API_KEY: ${{ secrets.API_KEY }}

Viewing Workflow Results

Check the Actions tab in your repository to see:

A list of all workflow runs with status (success, failure, in progress).
Detailed logs for each step.
Re-run options for failed workflows.

Common Use Cases

Automated testing — Run unit tests on every push or PR.
Build and package — Compile code and create release artifacts.
Deployment — Deploy to staging or production on merge to your release branch.
Linting — Check code style and formatting automatically.

The managed release pipeline

On MokoConsulting's own repositories, the shared CI/CD pipeline (distributed automatically by Sync Profiles) does the heavy lifting for you: a single tier-selecting deploy.yml builds and deploys to the right environment based on the branch, a universal auto-release.yml cuts stable releases, and a pre-release.yml publishes development-channel builds. Promotion follows the dev → rc → stable ladder. For the full picture, see MokoGIT: CI/CD & Release Pipeline and MokoGIT: Branch Model & Release Channels.

Runner Infrastructure

Moko Consulting manages the Gitea Actions runners for your MokoGIT instance. If you need custom runners (e.g., for specialized build environments or GPU workloads), contact our support team.

Last Updated: August 29, 2026

MokoGIT

Details: Category: MokoGIT

Applicable Software: MokoGIT
Min Version Number: 02.08.00
Max Version Number: Not Applicable

Bridge your AI assistant with Dolibarr ERP/CRM using dolibarr-api-mcp — an 85-tool MCP server for invoices, proposals, orders, products, projects, tasks, contacts, tickets, documents, and more, all directly from Claude Code.

Last Updated: August 23, 2026

Logging In

Your MokoGitea account is created by your Moko Consulting administrator. To log in:

Navigate to your MokoGitea instance URL (provided by your administrator).
Enter your username and password.
Click Sign In.

If you've forgotten your password, use the Forgot Password link on the login page, or contact your administrator.

The Dashboard

After logging in, you'll see your Dashboard, which shows:

Activity Feed — Recent actions from repositories you follow or contribute to.
Your Repositories — Quick access to repos you own or have been added to.
Organizations — Teams and groups you belong to.

Setting Up Your Profile

Click your avatar in the top-right corner and select Settings.
Update your display name, bio, and avatar.
Optionally add your website and location.
Click Update Profile to save.

Creating Your First Repository

Click the + icon in the top navigation bar and select New Repository.
Enter a Repository Name (e.g., my-first-project).
Add an optional Description.
Choose Private or Public visibility.
Check Initialize this repository to create it with a README file.
Click Create Repository.

Cloning Your Repository Locally

Once your repository is created, clone it to your local machine:

git clone https://your-mokogitea-url/username/my-first-project.git
cd my-first-project

You can also use SSH if you've set up SSH keys.

Making Your First Commit

Create or edit a file in your cloned repository.

Stage and commit your changes:

git add .
git commit -m "My first commit"

Push to MokoGitea:
```
git push origin main
```

Refresh your repository page in MokoGitea to see your changes.

Last Updated: August 23, 2026

Details: Category: MokoGIT

Applicable Software: MokoGIT
Min Version Number: 02.08.00
Max Version Number: Not Applicable

Using Issues

MokoGitea's built-in issue tracker helps you report bugs, request features, and manage tasks within each repository.

Creating an Issue

Navigate to your repository and click the Issues tab.
Click New Issue.
Enter a descriptive Title and detailed Description (Markdown is supported).
Optionally assign Labels, a Milestone, and an Assignee.
Click Submit New Issue.

Labels

Labels help categorize issues (e.g., bug, enhancement, documentation). Create and manage labels under Issues → Labels. Use colors and descriptions to keep your team aligned.

Milestones

Milestones group related issues into a release or sprint. Create milestones under Issues → Milestones with a title, description, and optional due date. Track progress via the milestone's completion percentage.

Assigning Issues

Assign issues to team members to clarify ownership. You can assign multiple people to a single issue if collaboration is needed.

Project Boards

MokoGitea supports Kanban-style project boards for visual task management.

Go to the Projects tab in your repository (or organization).
Click New Project and give it a name.
Add columns like To Do, In Progress, and Done.
Drag and drop issues between columns as work progresses.

Linking Issues to Pull Requests

Reference an issue in a pull request or commit message using #issue-number (e.g., Fixes #42). When the pull request is merged, the linked issue will automatically close.

Tips

Use issue templates (stored in .gitea/ISSUE_TEMPLATE/) to standardize bug reports and feature requests.
Subscribe to issues to receive notifications about updates.
Use @mentions to notify specific team members in comments.

Last Updated: August 23, 2026

MokoGIT

Details: Category: MokoGIT

Applicable Software: MokoGIT
Min Version Number: 02.10.00
Max Version Number: Not Applicable

Sync profiles decide which repositories a template's workflows and files get synced into. Traditionally a profile matches repos by their registered platform metadata. The new applies_to field adds a second, text-based way to match: it looks directly at each repo's root Makefile.

What `applies_to` does

applies_to is a list of regular expressions (one per line). At sync time, MokoGIT reads the candidate repo's root Makefile and checks each expression against it. If any line matches, the repo is a member of the profile.

This runs in addition to the normal platform match — the two are combined as a union:

A repo joins the profile if its platform metadata matches OR any applies_to expression matches its Makefile.

Because it only reads the Makefile, applies_to can match a repo that has no platform registered at all. You don't need to pre-register a platform or pass any “known platform” check — if the Makefile says PLATFORM = something, you can target it.

When to use it

Use applies_to when you want a profile to cover repos by what their Makefile declares, rather than by a registered platform. A common case: pulling in new or infrastructure repos that set PLATFORM=<x> in their Makefile before any platform entry exists for them.

How to match `PLATFORM = <x>`

Repos declare their platform in the Makefile, for example:

PLATFORM = go

The declaration can use =, :=, or ?=, with different spacing. To match all of those forms reliably, use this expression (replace <x> with your platform name):

(?m)^\s*PLATFORM\s*[:?]?=\s*<x>\b

What the pieces do:

(?m) — checks each line of the Makefile independently.
^\s*PLATFORM — the line must begin with PLATFORM (so commented-out lines starting with # are skipped).
\s*[:?]?=\s* — accepts =, :=, and ?=, with any spaces around them.
\b — a word boundary, so PLATFORM=php won't accidentally match a profile looking for phpfpm (and vice-versa).

Worked example: match every `PLATFORM=go` repo

To make a profile include every repository whose Makefile declares Go as its platform:

# match any repo whose Makefile declares PLATFORM = go
(?m)^\s*PLATFORM\s*[:?]?=\s*go\b

Any repo with PLATFORM = go, PLATFORM:=go, or PLATFORM ?= go in its root Makefile is now included — even one with no Go platform registered — together with whatever the profile's platform selector already matched.

Comments

Lines that begin with # in the applies_to list are treated as comments and ignored, so you can label what each expression is for (as shown above).

Notes

Expressions are evaluated at sync-resolution time, against the Makefile on the repo's default branch. No build or checkout of other branches happens.
An empty or missing applies_to simply falls back to platform-only matching — existing profiles behave exactly as before.

Last Updated: August 28, 2026

🛎️ Prefer white‑glove setup?

Moko Consulting can provision the line, port your number, tune policies, and hand you a zero‑drama system with a one‑page runbook.

Find out More Here or Contact us to find out more!

📝 Open Support Ticket ☎️ Call ‪(931) 279-6313

MokoGIT

CI/CD with Gitea Actions

What are Gitea Actions?

Creating Your First Workflow

Example: Basic CI Pipeline

Workflow Triggers

Secrets and Variables

Viewing Workflow Results

Common Use Cases

The managed release pipeline

Runner Infrastructure

Dolibarr API MCP Server

Getting Started: Your Account and First Repository

Logging In

The Dashboard

Setting Up Your Profile

Creating Your First Repository

Cloning Your Repository Locally

Making Your First Commit

Issues and Project Management

Using Issues

Creating an Issue

Labels

Milestones

Assigning Issues

Project Boards

Linking Issues to Pull Requests

Tips

Matching repos to sync profiles by Makefile PLATFORM (applies_to)

What `applies_to` does

When to use it

How to match `PLATFORM = <x>`

Worked example: match every `PLATFORM=go` repo

Comments

Notes

🛎️ Prefer white‑glove setup?

MokoGIT

CI/CD with Gitea Actions

What are Gitea Actions?

Creating Your First Workflow

Example: Basic CI Pipeline

Workflow Triggers

Secrets and Variables

Viewing Workflow Results

Common Use Cases

The managed release pipeline

Runner Infrastructure

Dolibarr API MCP Server

Getting Started: Your Account and First Repository

Logging In

The Dashboard

Setting Up Your Profile

Creating Your First Repository

Cloning Your Repository Locally

Making Your First Commit

Issues and Project Management

Using Issues

Creating an Issue

Labels

Milestones

Assigning Issues

Project Boards

Linking Issues to Pull Requests

Tips

Matching repos to sync profiles by Makefile PLATFORM (applies_to)

What applies_to does

When to use it

How to match PLATFORM = <x>

Worked example: match every PLATFORM=go repo

Comments

Notes

🛎️ Prefer white‑glove setup?

What `applies_to` does

How to match `PLATFORM = <x>`

Worked example: match every `PLATFORM=go` repo