Mueve los reusable workflows a .gitea/workflows/ (restriccion real de Gitea: workflow_call no puede vivir en una ruta arbitraria, confirmado en vivo). Corrige todos los 'uses:' cross-repo a URL absoluta (https://gitea.cruzcloud.net/...) -- la forma corta de GitHub se resuelve contra github.com en esta instancia, confirmado en vivo con un test real (reusable workflow + composite action ejecutando gitleaks de punta a punta). Limpia los archivos de prueba.
Arquetipo: API Node/Express (sin SSR)
Cuándo usar este arquetipo: una API backend en Node.js/TypeScript (Express,
Fastify, Medusa, NestJS, etc.) que expone endpoints HTTP, sin código de
UI propio. Si tu app renderiza páginas del lado del servidor, usá
archetype-nextjs-frontend en cambio.
Qué asume de tu repo:
- Un
Dockerfileenapp_dirbasado en (o compatible con)dockerfiles/node-api.Dockerfile. - Un endpoint
/health(o el que definas en tu overlay dek8s-manifests) que devuelva 200. cosign.pubcommiteado enapp_dir.- Un manifiesto K8s (
manifest_file) con la imagen a actualizar tras cada build.
Dónde vive el archivo real
Igual que los otros 2 arquetipos: el workflow_call tiene que estar
bajo .gitea/workflows/ (restricción real de Gitea, ver
pipelines/archetype-nextjs-frontend/README.md para el detalle
completo del hallazgo). Archivo real:
.gitea/workflows/archetype-node-api.yaml
Cómo usarlo desde tu repo
jobs:
build:
uses: https://gitea.cruzcloud.net/devops/platform-templates/.gitea/workflows/archetype-node-api.yaml@main
with:
app_dir: api
image_name: gitea.cruzcloud.net/devops/mi-api
manifest_file: workloads/mi-api/deployment.yaml
secrets:
REGISTRY_USER: ${{ secrets.REGISTRY_USER }}
REGISTRY_PASSWORD: ${{ secrets.REGISTRY_PASSWORD }}
COSIGN_PRIVATE_KEY: ${{ secrets.COSIGN_PRIVATE_KEY }}
COSIGN_PASSWORD: ${{ secrets.COSIGN_PASSWORD }}
Mismas advertencias que el arquetipo de Next.js sobre uses: con URL
absoluta y sobre fijar @main vs un tag/commit — no las repito acá, ver
ese README.
Semgrep: por qué este ruleset
p/typescript,p/security-audit,p/owasp-top-ten — sin p/react/p/nextjs
(no hay código de UI), con OWASP Top 10 sumado porque una API expuesta
públicamente es exactamente el tipo de superficie que ese ruleset cubre
(inyección, auth rota, etc.).
Sobre npm/npx en runtime
dockerfiles/node-api.Dockerfile borra npm de la imagen de runtime a
propósito (reduce superficie de CVEs — ver comentario en el propio
Dockerfile). Si tu app tiene un init container o un job que corre
npx algo, va a fallar contra esta imagen. Invocá el binario/CLI
directo con node, como hace el CMD del propio Dockerfile — no
agregues npm de vuelta solo para eso (esto rompió un pipeline real del
lab una vez, ver docs-portal → playbooks → contención de recursos y
el propio commit histórico de commerce-backend sobre este tema).