# 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`:

```yaml
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).