kicad-ci/.gitea/workflows/README.md

Gitea Actions — KiCad CI

Sibling implementation of kibot-ci.yml (GitLab) for projects hosted on Gitea. Same fab pipeline, same Astable upload contract; only the orchestration layer differs.

Per-project setup

In each PCB project's repo, create .gitea/workflows/ci.yml:

name: KiCad CI
on:
  push:
    branches: [dev, main]
  pull_request:
    branches: [dev, main]

jobs:
  kicad:
    uses: Micromelon/kicad-ci/.gitea/workflows/kibot.yml@main
    with:
      project_name: m100301-dengus_cab_tablet_mainboard
    secrets:
      ASTABLE_URL: ${{ secrets.ASTABLE_URL }}
      ASTABLE_API_TOKEN: ${{ secrets.ASTABLE_API_TOKEN }}

Adjust project_name per project. The PCB project's .gitlab (sic) submodule still points at the same Micromelon/kicad-ci repo — keeping the submodule path identical to the GitLab side means scripts/upload-bom.sh, configs/*.kibot.yaml, etc. are reachable from both platforms without per-platform path branching.

Secrets

Set at the org level (Org → Settings → Actions → Secrets) so every PCB repo picks them up automatically. Same shape as the GitLab CI variables on Micromelon/:

• ASTABLE_URL — e.g. https://astable.timhadwen.com
• ASTABLE_API_TOKEN — ast_… minted at /manage/api-tokens

Differences vs the GitLab side

• Each stage's artifacts are separate (Fabrication, Fabrication-bom, Fabrication-3d, …) and the astable jobs download-artifact them all into one directory. GitLab pools them automatically; Gitea Actions doesn't.
• Version extraction reads from the commit message (main branch) or the PR title (MR-to-main). Same V-token rule.
• Panel job uses continue-on-error: true to match GitLab's optional: true semantics.

Reusable-workflow support

Requires Gitea ≥ 1.21 (with Forgejo Actions / Gitea Actions support). If your runner is older, vendor this file into each PCB project's .gitea/workflows/ directly (drop the workflow_call: trigger and add a push: / pull_request: trigger).