feat(ci): plantillas de CI/CD propias para repos Go #1

Merged

julio.caicedo merged 2 commits from ci/plantillas-go into main 2026-10-05 14:37:49 +00:00

Conversation 0 Commits 2 Files changed 14 +1264 -27

julio.caicedo commented 2026-10-04 16:15:00 +00:00

Owner

Copy link

Las plantillas actuales son multilenguaje y de diciembre de 2025. Para un
repo Go dejan cuatro huecos que impiden probar y publicar bien:

• _test.yaml no levanta base de datos, así que no se puede probar nada que
  dependa de Postgres real: FOR UPDATE SKIP LOCKED, índices únicos parciales,
  concurrencia. Tampoco corre lint.
• _build-docker.yaml construye una sola arquitectura, y publica antes de
  escanear: si Trivy encuentra algo crítico, la imagen ya está en el registry.
• _deploy-k8s.yaml asume un deployment por servicio, namespaces fijos y no
  tiene paso de migración.
• No hay govulncheck ni gitleaks, que es lo que mira el módulo Go y el
  historial; Trivy solo ve la imagen.

Se añaden cuatro workflows reutilizables específicos de Go, sin tocar los
existentes:

_go-test.yaml lint, unitarias con puerta de cobertura, componente
contra Postgres real y e2e con docker compose
_go-analytics.yaml govulncheck, gitleaks, Opengrep y SonarQube
_go-build.yaml buildx multi-arquitectura, escaneo previo a publicar,
SBOM y digest de salida
_go-deploy.yaml migración como Job que bloquea el rollout, varios
deployments por repo, despliegue por digest y rollback

Decisiones que vale la pena mirar en la revisión:

• La cobertura se mide sobre el código propio: el perfil se filtra antes de
  medir, quitando cmd/, generados, mocks y testdata. Un 90% que incluye el
  cliente generado se sube escribiendo pruebas de lo que no importa.
• package_threshold permite pisos por paquete más altos que el global, para
  el código donde una falla cuesta plata.
• Componente y e2e vienen apagados: un repo Go simple pasa sin configurar.
• El namespace del deploy es obligatorio y explícito, sin valor heredado.
• Los overlays de kustomize viven en el repo, no como plantillas con sed
  clonadas desde infra.

Cadena de suministro y manejo de secretos:

• Todas las acciones de terceros quedan fijadas por SHA de 40 caracteres,
  con la versión en un comentario al lado. Ninguna referencia móvil.
• golangci-lint y kubectl se instalan fijados en vez de usar acciones:
  el primero con 'go install', que verifica contra la base de sumas de Go;
  el segundo descargando y comprobando el sha256 publicado. El job del
  deploy es el único que tiene el kubeconfig, y cuanto menos código ajeno
  corra ahí, mejor.
• Se elimina el 'curl | bash' de kustomize desde la rama master: no hacía
  falta, porque 'kubectl apply -k' ya trae kustomize incorporado.
• El secreto de módulos privados va en línea a BuildKit: no se escribe
  ningún .netrc en el contexto de build, así que no hay archivo que una
  acción de terceros pueda leer ni que termine horneado en la imagen.
• El manifiesto del Job de migración se arma en Python leyendo variables de
  entorno. Ninguna entrada se interpola dentro del YAML ni pasa por el
  shell, así que un comando con comillas, $ o saltos de línea no inyecta.
• gitleaks y opengrep fijados por versión en vez de :latest.

Falta verificar contra el runner, no está probado: si admite contenedores
de servicio, si admite buildx con QEMU, y si el caché type=gha funciona o
hay que pasarlo a type=registry.

Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_012oVizRo2WB4FeZVRnHr9Ye

Las plantillas actuales son multilenguaje y de diciembre de 2025. Para un repo Go dejan cuatro huecos que impiden probar y publicar bien: - _test.yaml no levanta base de datos, así que no se puede probar nada que dependa de Postgres real: FOR UPDATE SKIP LOCKED, índices únicos parciales, concurrencia. Tampoco corre lint. - _build-docker.yaml construye una sola arquitectura, y publica antes de escanear: si Trivy encuentra algo crítico, la imagen ya está en el registry. - _deploy-k8s.yaml asume un deployment por servicio, namespaces fijos y no tiene paso de migración. - No hay govulncheck ni gitleaks, que es lo que mira el módulo Go y el historial; Trivy solo ve la imagen. Se añaden cuatro workflows reutilizables específicos de Go, sin tocar los existentes: _go-test.yaml lint, unitarias con puerta de cobertura, componente contra Postgres real y e2e con docker compose _go-analytics.yaml govulncheck, gitleaks, Opengrep y SonarQube _go-build.yaml buildx multi-arquitectura, escaneo previo a publicar, SBOM y digest de salida _go-deploy.yaml migración como Job que bloquea el rollout, varios deployments por repo, despliegue por digest y rollback Decisiones que vale la pena mirar en la revisión: - La cobertura se mide sobre el código propio: el perfil se filtra antes de medir, quitando cmd/, generados, mocks y testdata. Un 90% que incluye el cliente generado se sube escribiendo pruebas de lo que no importa. - package_threshold permite pisos por paquete más altos que el global, para el código donde una falla cuesta plata. - Componente y e2e vienen apagados: un repo Go simple pasa sin configurar. - El namespace del deploy es obligatorio y explícito, sin valor heredado. - Los overlays de kustomize viven en el repo, no como plantillas con sed clonadas desde infra. Cadena de suministro y manejo de secretos: - Todas las acciones de terceros quedan fijadas por SHA de 40 caracteres, con la versión en un comentario al lado. Ninguna referencia móvil. - golangci-lint y kubectl se instalan fijados en vez de usar acciones: el primero con 'go install', que verifica contra la base de sumas de Go; el segundo descargando y comprobando el sha256 publicado. El job del deploy es el único que tiene el kubeconfig, y cuanto menos código ajeno corra ahí, mejor. - Se elimina el 'curl | bash' de kustomize desde la rama master: no hacía falta, porque 'kubectl apply -k' ya trae kustomize incorporado. - El secreto de módulos privados va en línea a BuildKit: no se escribe ningún .netrc en el contexto de build, así que no hay archivo que una acción de terceros pueda leer ni que termine horneado en la imagen. - El manifiesto del Job de migración se arma en Python leyendo variables de entorno. Ninguna entrada se interpola dentro del YAML ni pasa por el shell, así que un comando con comillas, $ o saltos de línea no inyecta. - gitleaks y opengrep fijados por versión en vez de :latest. Falta verificar contra el runner, no está probado: si admite contenedores de servicio, si admite buildx con QEMU, y si el caché type=gha funciona o hay que pasarlo a type=registry. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012oVizRo2WB4FeZVRnHr9Ye

julio.caicedo added 1 commit 2026-10-04 16:15:00 +00:00

feat(ci): plantillas de CI/CD propias para repos Go ... 30e6fc6c96

Las plantillas actuales son multilenguaje y de diciembre de 2025. Para un
repo Go dejan cuatro huecos que impiden probar y publicar bien:

- _test.yaml no levanta base de datos, así que no se puede probar nada que
  dependa de Postgres real: FOR UPDATE SKIP LOCKED, índices únicos parciales,
  concurrencia. Tampoco corre lint.
- _build-docker.yaml construye una sola arquitectura, y publica antes de
  escanear: si Trivy encuentra algo crítico, la imagen ya está en el registry.
- _deploy-k8s.yaml asume un deployment por servicio, namespaces fijos y no
  tiene paso de migración.
- No hay govulncheck ni gitleaks, que es lo que mira el módulo Go y el
  historial; Trivy solo ve la imagen.

Se añaden cuatro workflows reutilizables específicos de Go, sin tocar los
existentes:

  _go-test.yaml       lint, unitarias con puerta de cobertura, componente
                      contra Postgres real y e2e con docker compose
  _go-analytics.yaml  govulncheck, gitleaks, Opengrep y SonarQube
  _go-build.yaml      buildx multi-arquitectura, escaneo previo a publicar,
                      SBOM y digest de salida
  _go-deploy.yaml     migración como Job que bloquea el rollout, varios
                      deployments por repo, despliegue por digest y rollback

Decisiones que vale la pena mirar en la revisión:

- La cobertura se mide sobre el código propio: el perfil se filtra antes de
  medir, quitando cmd/, generados, mocks y testdata. Un 90% que incluye el
  cliente generado se sube escribiendo pruebas de lo que no importa.
- package_threshold permite pisos por paquete más altos que el global, para
  el código donde una falla cuesta plata.
- Componente y e2e vienen apagados: un repo Go simple pasa sin configurar.
- El namespace del deploy es obligatorio y explícito, sin valor heredado.
- Los overlays de kustomize viven en el repo, no como plantillas con sed
  clonadas desde infra.

Cadena de suministro y manejo de secretos:

- Todas las acciones de terceros quedan fijadas por SHA de 40 caracteres,
  con la versión en un comentario al lado. Ninguna referencia móvil.
- golangci-lint y kubectl se instalan fijados en vez de usar acciones:
  el primero con 'go install', que verifica contra la base de sumas de Go;
  el segundo descargando y comprobando el sha256 publicado. El job del
  deploy es el único que tiene el kubeconfig, y cuanto menos código ajeno
  corra ahí, mejor.
- Se elimina el 'curl | bash' de kustomize desde la rama master: no hacía
  falta, porque 'kubectl apply -k' ya trae kustomize incorporado.
- El secreto de módulos privados va en línea a BuildKit: no se escribe
  ningún .netrc en el contexto de build, así que no hay archivo que una
  acción de terceros pueda leer ni que termine horneado en la imagen.
- El manifiesto del Job de migración se arma en Python leyendo variables de
  entorno. Ninguna entrada se interpola dentro del YAML ni pasa por el
  shell, así que un comando con comillas, $ o saltos de línea no inyecta.
- gitleaks y opengrep fijados por versión en vez de :latest.

Falta verificar contra el runner, no está probado: si admite contenedores
de servicio, si admite buildx con QEMU, y si el caché type=gha funciona o
hay que pasarlo a type=registry.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012oVizRo2WB4FeZVRnHr9Ye

julio.caicedo added 1 commit 2026-10-05 14:02:03 +00:00

refactor(ci): renombrar las referencias de startcodex/infra a startcodex/ci ... 4b23359ad7

El repositorio se llama infra por historia, pero su contenido son plantillas
de CI/CD: eso es lo que dice su propio README y lo que hay dentro. El nombre
ci describe lo que es.

Además hace falta que sea público. Forgejo no soporta workflows reutilizables
en repositorios privados: la referencia dice literalmente que el repositorio
destino debe ser público, y la v15 solo añadió que funcionen repos públicos
en instancias privadas. Hoy este repo responde 404 sin autenticar, así que
ningún 'uses:' que apunte aquí puede resolverse.

Eso explica por qué las plantillas llevaban diez meses sin consumidores: el
único ejemplo que las llamaba está muerto, y el único repo vivo con CI se
escribe su propio workflow a mano.

El README ofrecía INFRA_CLONE_TOKEN como alternativa para repo privado, pero
ese token solo sirve para el git clone de los manifiestos dentro del job de
deploy: no interviene en la resolución del 'uses:'. La opción B nunca pudo
funcionar para lo que importa.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012oVizRo2WB4FeZVRnHr9Ye

julio.caicedo merged commit e97227e41c into main 2026-10-05 14:37:49 +00:00

julio.caicedo deleted branch ci/plantillas-go 2026-10-05 14:37:49 +00:00

julio.caicedo referenced this pull request from a commit 2026-10-05 14:37:50 +00:00

Merge pull request 'feat(ci): plantillas de CI/CD propias para repos Go' (#1) from ci/plantillas-go into main

julio.caicedo referenced this pull request from a commit 2026-10-23 12:43:04 +00:00

fix: el borrador corta referencias, menciones y entidades HTML

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

startcodex/ci!1

No description provided.