forgejo-ci

CI mínima común y reutilizable para los repos de andres20980 en https://andres20980.es/repos. Un solo workflow, versionado, que detecta el stack del repo que lo llama.

Qué ejecuta

Fase	Qué hace
detectar	Deduce el stack: node, python, go, rust, shell
calidad	Formato y lint según stack (ruff, gofmt+go vet, clippy, shellcheck, scripts npm)
tests	Suite del repo si existe; no inventa tests donde no los hay
compilar	Build del stack (omitible con skip-build)
secretos	Escaneo de patrones de alto valor sin dependencias externas
dependencias	npm audit, pip-audit, govulncheck, cargo audit
workflows	Valida los propios workflows: YAML, runs-on, refs móviles
sbom	Inventario CycloneDX, huellas SHA-256 y procedencia; omitible con skip-sbom
resultado	Agregado obligatorio — el único job que hay que exigir

Cómo adoptarlo

En el repo consumidor, .forgejo/workflows/ci.yml:

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

jobs:
  ci:
    uses: andres20980/forgejo-ci/.forgejo/workflows/ci-comun.yml@<SHA>

Fija siempre por SHA, nunca por rama: una rama móvil convierte tu CI en algo irreproducible, y la propia fase workflows lo marca como error.

Principios

• Nada de acciones de terceros no fijadas; el escáner de secretos no usa binarios externos.
• Los pasos ausentes no fallan: si el repo no define lint o test, se omiten en vez de dar rojo falso.
• Un único resultado agregado, para que la promoción a producción dependa de una sola señal.
• El SBOM sale de la herramienta del propio stack (npm sbom, cyclonedx-py, cyclonedx-gomod, cargo-cyclonedx), no de una acción de terceros: el generador del inventario no debe ser el eslabón que comprometa la cadena que documenta.
• La procedencia es SLSA nivel 1: deja por escrito quién construyó qué, desde qué commit y con qué workflow. No va firmada; una atestación firmada exige un constructor aislado (L2+), que este runner todavía no ofrece.