Configuration CI/CD

Exécuter steadycron plan sur chaque pull request et steadycron apply --prune lors du merge transforme votre manifeste en flux de travail GitOps : les réviseurs voient exactement quels changements de cron un PR introduit, et la branche principale est toujours la source de vérité.

Prérequis

• Une clé API SteadyCron (créez-en une dans Paramètres → Clés API)
• Votre manifeste commité dans le dépôt (voir Migrer vers IaC)

Étape 1 — ajouter la clé API comme secret

Dans votre dépôt GitHub, allez dans Settings → Secrets and variables → Actions et ajoutez :

Nom	Valeur
STEADYCRON_API_KEY	Votre clé API SteadyCron (sc_...)

Ajoutez tout autre secret spécifique à l’environnement référencé dans votre manifeste (p. ex. SLACK_WEBHOOK_URL).

Pour les pipelines en lecture seule (opérations de plan uniquement), vous pouvez créer une clé API dédiée en lecture seule et l’utiliser exclusivement dans le flux de travail de PR.

Workflow 1 — diff du plan sur pull request

Publiez la sortie du plan en tant que commentaire de PR chaque fois qu’un fichier de manifeste change :

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

L’action publie un commentaire de ce type :

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 — application lors du merge

Appliquez le manifeste (avec --prune) chaque fois que la branche principale est mise à jour :

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

Entrées de l’action

Entrée	Description	Par défaut
command	plan, apply, validate ou sync	plan
manifest	Chemin vers le fichier ou le répertoire de manifeste	—
prune	Si true, passe --prune à apply	false
comment-on-pr	Si true, publie la sortie du plan en commentaire de PR	false

Tous les espaces réservés ${ENV_VAR} dans votre manifeste sont lus depuis l’environnement du job — transmettez-les via le bloc env: dans l’étape de votre workflow.

Environnements multiples

Gérez des manifestes distincts pour le staging et la production avec une matrice :

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

Clés API avec le moindre privilège

Pour les workflows en lecture seule (commentaires de PR), utilisez une clé API en lecture seule qui ne peut pas effectuer de modifications. Créez une clé dédiée dans le dashboard avec uniquement le scope read et stockez-la comme secret distinct (p. ex. STEADYCRON_API_KEY_RO).

Cela limite l’impact en cas de compromission du secret du workflow de PR.

Valider à chaque push

Ajoutez un job de validation pour détecter les erreurs de schéma avant l’exécution du plan :

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

validate se termine avec un code non nul en cas d’erreurs de schéma et ne nécessite pas de clé API, mais en fournir une permet au serveur de valider les données par rapport aux limites actuelles de votre compte.

Liens connexes

• Flux de travail IaC — toutes les commandes CLI expliquées
• Migrer vers IaC — adopter un compte existant
• Référence du manifeste — référence complète des champs