GitHub Actions para pruebas Go con vendor

Configurar GitHub Actions para correr pruebas automáticas en Go es más simple de lo que parece. Aquí verás, paso a paso, cómo preparar dependencias con vendor, crear una prueba dummy con testify/require y escribir un workflow en YAML que se ejecute en cada push. Sin atajos, solo lo esencial para que funcione bien.

¿Cómo preparar dependencias de Go con vendor y go mod?

Antes de automatizar, es clave tener las dependencias limpias. Cuando cambias de rama o dejas de usar una librería, el módulo puede aparecer en rojo por inconsistencias. La corrección es directa: sincronizar y compilar.

• Ejecuta "go mod vendor" para actualizar dependencias en el vendor.
• Luego corre "go mod build" para validar la compilación.
• Verás desaparecer el warning y todo quedará sincronizado.
• El directorio vendor no se versiona: se agrega a .gitignore.

Comandos útiles:

go mod vendor
go mod build

Conceptos clave que aplicas: - vendor: carpeta con dependencias locales usadas por el proyecto. - .gitignore: evita subir vendor al repositorio. - módulos de Go: gestionan librerías y sus versiones.

¿Cómo crear una prueba dummy en Go con testify/require?

Para validar el pipeline, basta una prueba sencilla. Se crea un archivo de prueba estándar y se usa el submódulo require de testify para aserciones claras.

• Crea el archivo de prueba "main test" con package main.
• Agrega la dependencia con "go get" de testify y el submódulo require.
• Importa require y sincroniza con "go mod vendor".
• Usa require.New para crear el contexto de aserciones.
• Define una variable result y valida su valor esperado.
• Corre localmente con "go test" para comprobar que pasa.

Puntos a tener en cuenta: - Las pruebas en Go deben iniciar con "Test" para que el testing las detecte. - go test corre desde la terminal como lo haría GitHub Actions.

¿Cómo escribir un workflow de GitHub Actions en YAML para correr go test?

La automatización replica lo que ya haces a mano. Se crea la carpeta oculta .github/workflows, se define un archivo YAML y se especifican eventos, jobs y steps.

¿Qué dispara el workflow y dónde corre?

• Evento: on: push para ejecutarlo en cada push.
• Ramas: branches: "*" para todas las ramas.
• Sistema operativo: Ubuntu 22.04 con runs-on.

¿Qué pasos ejecuta el pipeline?

• checkout code: usa actions/checkout para traer el código.
• setup go: usa actions/setup-go y fija la versión 1.18.
• install dependencies: corre "go mod vendor" en el working directory del proyecto (carpeta "GitHub tracker").
• check unit test: ejecuta "go test ./..." sobre todos los folders.
• continue on error: desactivado; si las pruebas fallan, no continúa.

Ejemplo de estructura en YAML basada en los pasos descritos:

name: test workflow
on:
  push:
    branches:
      - "*"
jobs:
  code validation:
    runs-on: ubuntu-22.04
    steps:
      - name: checkout code
        uses: actions/checkout@v4

      - name: setup go
        uses: actions/setup-go@v4
        with:
          go-version: "1.18"

      - name: install dependencies
        working-directory: "GitHub tracker"
        run: go mod vendor

      - name: check unit test
        working-directory: "GitHub tracker"
        run: go test ./...
        continue-on-error: false

Buenas prácticas que se aplican en el archivo YAML: - Mantener la identación correcta para evitar errores de sintaxis. - Ubicar steps justo debajo de runs-on dentro del job. - Nombrar cada paso con name para facilitar el seguimiento.

¿Quieres que sigamos afinando el pipeline o agregamos más pruebas con require? Cuéntame en los comentarios qué parte te gustaría profundizar.