keepercheky

🚀 Release Workflow - KeeperCheky

Descripción General

KeeperCheky utiliza un workflow unificado inspirado en Jellyseerr, que combina semantic-release y construcción de imágenes Docker en un solo pipeline.

🔄 Flujo del Proceso

graph LR
    A[Push a develop/stable] --> B[Semantic Release]
    B --> C{¿Nueva versión?}
    C -->|No| D[Fin]
    C -->|Sí| E[Crear CHANGELOG.md]
    E --> F[Crear commit chore]
    F --> G[Crear tag Git]
    G --> H[Push tag + commit]
    H --> I[Build Docker]
    I --> J[Push a GHCR]
    J --> K[Notificación]

📋 Workflow Unificado

KeeperCheky utiliza 3 workflows principales para gestionar CI/CD:

1. CI Workflow (.github/workflows/ci.yml)

Propósito: Validaciones rápidas para Pull Requests y pushes a ramas

Se ejecuta en:

Jobs en paralelo:

  1. Lint: Verifica formato de código
    • go fmt -s -l . (formato)
    • go vet ./... (análisis estático)
  2. Test: Ejecuta pruebas unitarias
    • go test -v -race -coverprofile=coverage.out ./...
    • Sube coverage a Codecov (opcional)
  3. Build: Compila el binario
    • CGO_ENABLED=1 go build -o bin/keepercheky ./cmd/server
    • Verifica que la compilación sea exitosa

Beneficios:

2. Release Workflow (.github/workflows/release.yml)

Propósito: Gestionar releases automáticos y construcción de imágenes

Archivo: .github/workflows/release.yml

El workflow se activa en:

Jobs:

1. semantic-release

2. build-and-push

3. notify

3. Docker Build Workflow (.github/workflows/docker-build.yml)

Propósito: Construcción directa de imágenes Docker desde tags

Se ejecuta en:

Jobs:

  1. build-and-push: Construye y publica imagen
    • Checkout del código en el tag
    • Construcción multi-arquitectura (linux/amd64, linux/arm64)
    • Push automático a GitHub Container Registry
    • Tags generados según el tipo de versión

Uso típico:

Nota: Este workflow es complementario a release.yml. En flujo normal, las imágenes se construyen vía release.yml.

🏷️ Estrategia de Tags

Rama develop (pre-release)

Versión: 1.0.0-dev.1
Tags Docker:
  - 1.0.0-dev.1
  - develop

Rama stable (producción)

Versión: 1.0.0
Tags Docker:
  - 1.0.0
  - 1.0
  - 1
  - latest
  - stable

📝 Commits Convencionales

El workflow usa Conventional Commits:

Tipo Release Descripción
feat minor Nueva funcionalidad
fix patch Corrección de bug
perf patch Mejora de rendimiento
refactor patch Refactorización de código
docs - Documentación
chore - Mantenimiento
test - Tests
BREAKING major Cambio incompatible

Ejemplos:

# Nueva funcionalidad (minor: 1.0.0 → 1.1.0)
git commit -m "feat(sync): add intelligent torrent matching"

# Corrección de bug (patch: 1.0.0 → 1.0.1)
git commit -m "fix(ui): resolve mobile tooltip display"

# Breaking change (major: 1.0.0 → 2.0.0)
git commit -m "feat(api)!: redesign configuration structure

BREAKING CHANGE: Config file format changed from YAML to TOML"

🔧 Configuración

.releaserc.json

{
  "branches": [
    { "name": "stable" },
    { "name": "develop", "prerelease": "dev" }
  ],
  "plugins": [
    "@semantic-release/commit-analyzer",
    "@semantic-release/release-notes-generator",
    "@semantic-release/changelog",
    "@semantic-release/git",
    "@semantic-release/github"
  ]
}

Secrets necesarios

🎯 Ventajas del Workflow Unificado

✅ Resuelve problemas anteriores:

  1. Tag triggering inconsistente: Ya no hay workflows separados
  2. CHANGELOG desactualizado en Docker: La imagen siempre contiene el changelog correcto
  3. Race conditions: Todo es secuencial en un solo workflow
  4. Complejidad: Un solo archivo vs. múltiples workflows coordinados

✅ Beneficios adicionales:

🧪 Cómo Probar

Escenario 1: Feature en develop

git checkout develop
git pull
echo "test" > test.txt
git add test.txt
git commit -m "feat(test): add test feature"
git push origin develop

Resultado esperado:

Escenario 2: Fix en develop

git commit -m "fix(test): correct test issue"
git push origin develop

Resultado esperado:

Escenario 3: Docs (sin release)

git commit -m "docs: update README"
git push origin develop

Resultado esperado:

📊 Monitoreo

Ver workflow en ejecución:

https://github.com/carcheky/keepercheky/actions

Ver releases:

https://github.com/carcheky/keepercheky/releases

Ver imágenes Docker:

https://github.com/carcheky/keepercheky/pkgs/container/keepercheky

🐛 Troubleshooting

El workflow no se ejecuta

No se crea nueva versión

Docker build falla

Tag no se crea

📚 Referencias

🔄 Migración desde Workflows Antiguos

Los workflows fueron reorganizados para optimizar CI/CD:

Workflows Actuales (Octubre 2025)

  1. release.yml: Gestiona releases automáticos con semantic-release
    • Se ejecuta en push a develop y stable
    • Genera versiones, tags y CHANGELOG
    • Construye y publica imágenes Docker cuando hay nueva versión
  2. docker-build.yml: Construcción directa de Docker (solo tags)
    • Se ejecuta cuando se crea un tag manualmente (v*)
    • Útil para reconstruir imágenes de versiones específicas
    • Push directo a GHCR
  3. ci.yml: Validaciones para Pull Requests
    • Linting (go fmt, go vet)
    • Tests unitarios con coverage
    • Build check del binario
    • Docker build check (sin push)
    • Se ejecuta en PRs y pushes a ramas principales

Workflows Antiguos (Renombrados)

Estos workflows están disponibles como referencia pero no se ejecutarán:

Última actualización: 2025-11-01 Versión workflow: 2.0.0

This site is open source. Improve this page.