Configuración CI/CD

Ejecutar steadycron plan en cada pull request y steadycron apply --prune al hacer merge convierte su manifiesto en un flujo de trabajo GitOps: los revisores ven exactamente qué cambios de cron introduce un PR, y la rama principal es siempre la única fuente de verdad.

Requisitos previos

• Una clave de API de SteadyCron (créela en Configuración → Claves de API)
• Su manifiesto committeado en el repositorio (consulte Migrar a IaC)

Paso 1 — añadir la clave de API como secret

En su repositorio de GitHub, vaya a Settings → Secrets and variables → Actions y añada:

Nombre	Valor
STEADYCRON_API_KEY	Su clave de API de SteadyCron (sc_...)

Añada cualquier otro secret específico del entorno al que haga referencia su manifiesto (p. ej., SLACK_WEBHOOK_URL).

Para pipelines de solo plan (operaciones de lectura), puede crear una clave de API de solo lectura separada y usarla exclusivamente en el flujo de trabajo de PR.

Flujo de trabajo 1 — diff del plan en pull request

Publique la salida del plan como comentario de PR cada vez que cambie un archivo de manifiesto:

# .github/workflows/cron-plan.yml
name: Cron plan

on:
  pull_request:
    paths:
      - 'manifests/**'

jobs:
  plan:
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write
    steps:
      - uses: actions/checkout@v4

      - uses: steadycron/action@v1
        with:
          command: plan
          manifest: manifests/production.yaml
          comment-on-pr: 'true'
        env:
          STEADYCRON_API_KEY: ${{ secrets.STEADYCRON_API_KEY }}
          SLACK_WEBHOOK_URL:  ${{ secrets.SLACK_WEBHOOK_URL }}

La action publica un comentario similar a este:

SteadyCron plan — manifests/production.yaml

  ~ weekly-digest    update  retries: 2 → 3
  + invoice-cron     create  http  0 17 * * 5

  1 to create · 1 to update · 0 to delete

Flujo de trabajo 2 — aplicar al hacer merge

Aplique el manifiesto (con --prune) cada vez que se actualice la rama principal:

# .github/workflows/cron-apply.yml
name: Cron apply

on:
  push:
    branches:
      - main
    paths:
      - 'manifests/**'

jobs:
  apply:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: steadycron/action@v1
        with:
          command: apply
          manifest: manifests/production.yaml
          prune: 'true'
        env:
          STEADYCRON_API_KEY: ${{ secrets.STEADYCRON_API_KEY }}
          SLACK_WEBHOOK_URL:  ${{ secrets.SLACK_WEBHOOK_URL }}

Entradas de la action

Entrada	Descripción	Por defecto
command	plan, apply, validate o sync	plan
manifest	Ruta al archivo de manifiesto o directorio	—
prune	Si es true, pasa --prune a apply	false
comment-on-pr	Si es true, publica la salida del plan como comentario de PR	false

Todos los marcadores de posición ${ENV_VAR} en su manifiesto se leen del entorno del job — páselos mediante el bloque env: en el paso de su flujo de trabajo.

Múltiples entornos

Gestione manifiestos separados de staging y producción con una matriz:

jobs:
  apply:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        env: [staging, production]
    steps:
      - uses: actions/checkout@v4
      - uses: steadycron/action@v1
        with:
          command: apply
          manifest: manifests/${{ matrix.env }}.yaml
          prune: 'true'
        env:
          STEADYCRON_API_KEY: ${{ secrets[format('STEADYCRON_API_KEY_{0}', matrix.env)] }}

Claves de API con mínimos privilegios

Para flujos de trabajo de solo plan (comentarios de PR), use una clave de API de solo lectura que no pueda realizar cambios. Cree una clave separada en el dashboard con scope de solo lectura y guárdela como un secret separado (p. ej., STEADYCRON_API_KEY_RO).

Esto limita el radio de impacto en caso de que el secret del flujo de trabajo de PR quede comprometido.

Validar en cada push

Añada un job de validación para detectar errores de esquema antes de que se ejecute el plan:

- uses: steadycron/action@v1
  with:
    command: validate
    manifest: manifests/production.yaml
  env:
    STEADYCRON_API_KEY: ${{ secrets.STEADYCRON_API_KEY }}

validate termina con código distinto de cero ante errores de esquema y no requiere una clave de API, aunque si proporciona una, el servidor puede validar contra los límites actuales de su cuenta.

Temas relacionados

• Flujo de trabajo IaC — todos los comandos CLI explicados
• Migrar a IaC — adoptar una cuenta existente
• Referencia del manifiesto — referencia completa de campos