Files
platform-templates/pipelines/archetype-node-api
devops a3c022c024 docs: READMEs completos, estructura final de arquetipos
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.
2026-08-17 00:23:24 -05:00
..

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 Dockerfile en app_dir basado en (o compatible con) dockerfiles/node-api.Dockerfile.
  • Un endpoint /health (o el que definas en tu overlay de k8s-manifests) que devuelva 200.
  • cosign.pub commiteado en app_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).