CI/CD-Einrichtung

steadycron plan in jedem Pull Request und steadycron apply --prune beim Merge verwandeln Ihr Manifest in einen GitOps-Workflow: Prüfer sehen genau, welche Cron-Änderungen ein PR einführt, und der Main-Branch ist stets die einzige Quelle der Wahrheit.

Voraussetzungen

• Ein SteadyCron-API-Schlüssel (erstellen Sie ihn unter Einstellungen → API-Schlüssel)
• Ihr Manifest im Repository (siehe Zu IaC migrieren)

Schritt 1 — API-Schlüssel als Secret hinterlegen

Gehen Sie in Ihrem GitHub-Repository zu Settings → Secrets and variables → Actions und fügen Sie Folgendes hinzu:

Name	Wert
STEADYCRON_API_KEY	Ihr SteadyCron-API-Schlüssel (sc_...)

Fügen Sie weitere umgebungsspezifische Secrets hinzu, auf die Ihr Manifest verweist (z. B. SLACK_WEBHOOK_URL).

Für reine Plan-Pipelines (Lesezugriff) können Sie einen separaten Read-Only-API-Schlüssel erstellen und diesen ausschließlich im PR-Workflow verwenden.

Workflow 1 — Plan-Diff beim Pull Request

Geben Sie die Plan-Ausgabe als PR-Kommentar aus, sobald sich eine Manifest-Datei ändert:

# .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 }}

Die Action erstellt einen Kommentar in etwa dieser Form:

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

Workflow 2 — Anwenden beim Merge

Wenden Sie das Manifest (mit --prune) an, sobald der Main-Branch aktualisiert wird:

# .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 }}

Action-Eingaben

Eingabe	Beschreibung	Standard
command	plan, apply, validate oder sync	plan
manifest	Pfad zur Manifest-Datei oder zum Verzeichnis	—
prune	Bei true wird --prune an apply übergeben	false
comment-on-pr	Bei true wird die Plan-Ausgabe als PR-Kommentar gepostet	false

Alle ${ENV_VAR}-Platzhalter in Ihrem Manifest werden aus der Job-Umgebung gelesen — übergeben Sie sie über den env:-Block in Ihrem Workflow-Schritt.

Mehrere Umgebungen

Verwalten Sie separate Staging- und Production-Manifeste mit einer Matrix:

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)] }}

API-Schlüssel mit minimalen Rechten

Für reine Plan-Workflows (PR-Kommentare) verwenden Sie einen Read-Only-API-Schlüssel, der keine Änderungen vornehmen kann. Erstellen Sie im Dashboard einen separaten Schlüssel mit ausschließlich read-Scope und speichern Sie ihn als separates Secret (z. B. STEADYCRON_API_KEY_RO).

Dadurch begrenzen Sie den Schaden, falls das Secret des PR-Workflows jemals kompromittiert wird.

Validierung bei jedem Push

Fügen Sie einen Validate-Job hinzu, um Schema-Fehler abzufangen, bevor Plan ausgeführt wird:

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

validate beendet sich mit einem Nicht-Null-Exit-Code bei Schema-Fehlern und benötigt keinen API-Schlüssel. Wenn Sie jedoch einen angeben, kann der Server die Daten gegen die aktuellen Limits Ihres Kontos prüfen.

Weiterführende Themen

• IaC-Workflow — alle CLI-Befehle erklärt
• Zu IaC migrieren — ein bestehendes Konto übernehmen
• Manifest-Referenz — vollständige Feldreferenz