Flux de travail IaC

Comment adopter, valider, prévisualiser et appliquer un manifeste YAML SteadyCron — du premier export à l'automatisation CI/CD.

La CLI SteadyCron transforme votre compte en un fichier texte que vous pouvez versionner, réviser dans des PRs et déployer depuis la CI. Cette page couvre chaque commande du flux de travail.

Prérequis {#prerequisites}

Installer la CLI

Option 1 — outil global .NET (recommandé)

Nécessite le runtime .NET 10.

dotnet tool install -g steadycron
steadycron --version

Mettez à jour plus tard avec dotnet tool update -g steadycron.

Option 2 — binaire autonome

Aucun runtime requis. Téléchargez le binaire depuis la page Releases :

# Linux x64
curl -Lo steadycron https://github.com/steadycron/cli/releases/latest/download/steadycron-linux-x64
chmod +x steadycron && sudo mv steadycron /usr/local/bin/

Les binaires pour Linux arm64, macOS et Windows se trouvent sur la même page Releases.

Authentification

Créez une clé API sous Paramètres → Clés API dans le dashboard. Les commandes mutantes (apply, sync, jobs create, etc.) nécessitent une clé d’accès complet ; export, validate et plan fonctionnent avec une clé en lecture seule.

Définissez la clé dans votre environnement :

export STEADYCRON_API_KEY=sc_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Ou enregistrez-la dans le fichier de configuration pour qu’elle persiste entre les sessions shell :

steadycron config set --api-key sc_...

Vérifiez la connectivité :

steadycron config show --check

Commandes en un coup d’œil

Commande	Ce qu’elle fait
`steadycron export`	Exporter l’état actuel du compte vers un manifeste
`steadycron validate`	Vérifier un manifeste pour des erreurs de schéma
`steadycron plan`	Prévisualiser ce qui changerait — sans écriture
`steadycron sync`	Appliquer les changements (créer + mettre à jour ; sans suppressions)
`steadycron apply`	Appliquer les changements ; ajoutez `--prune` pour aussi supprimer

Étape 1 — export (adoption d’un compte existant)

Si vous avez déjà des jobs dans le dashboard, export les transfère dans un manifeste pour que vous puissiez commencer à les gérer comme du code sans rien perdre :

export STEADYCRON_API_KEY=sc_...
steadycron export --namespace production > manifests/production.yaml

Le fichier exporté est sûr à commiter. Les clés API, URLs de webhook et autres secrets sont remplacés par des espaces réservés ${VAR_NAME} — vous fournissez les valeurs réelles via des variables d’environnement au moment de l’application. Les variables de gabarit ({{var}}) dans les champs de jobs HTTP sont conservées telles quelles.

Examinez le fichier, ajoutez des valeurs id aux jobs qui n’en ont pas, et commitez.

Étape 2 — validate

Vérifiez un manifeste pour des erreurs de schéma avant de l’appliquer :

steadycron validate manifests/production.yaml

Termine avec 0 en cas de succès, 1 avec une liste d’erreurs en cas d’échec. Intégrez ceci dans la CI comme vérification préliminaire sur chaque PR.

Étape 3 — plan

plan vous montre exactement ce qui changerait — dans un format similaire à terraform plan — sans rien écrire :

steadycron plan manifests/production.yaml

Exemple de sortie :

  ~ weekly-digest       update  retries: 2 → 3
  + invoice-reminder    create  kind: http  schedule: 0 17 * * 5
  - old-report          (not in manifest — would be deleted with --prune)

  1 to create · 1 to update · 1 pending deletion

Utilisez ceci dans votre pipeline de PR pour commenter le diff du plan sur chaque pull request. Consultez Configuration CI/CD pour l’action GitHub qui le fait automatiquement.

Étape 4 — sync / apply

sync crée les nouveaux jobs et met à jour ceux qui ont changé. Il ne supprime pas les jobs qui existent dans votre compte mais sont absents du manifeste :

steadycron sync manifests/production.yaml

Pour supprimer également les jobs non gérés (ceux dans le namespace mais absents du fichier), utilisez apply --prune :

steadycron apply --prune manifests/production.yaml

apply est transactionnel : si une opération échoue, le reste du lot n’est pas appliqué et l’erreur est signalée avec la ressource spécifique qui l’a causée.

Dry-run

Passez --dry-run à tout appel sync ou apply pour afficher ce qui se passerait sans effectuer de changements — équivalent à plan mais utile dans les scripts :

steadycron apply --prune --dry-run manifests/production.yaml

Namespaces et propriété {#namespaces}

Un namespace délimite les ressources que gère la CLI. Sans namespace, la CLI opère sur le namespace par défaut et ne peut pas utiliser --prune en toute sécurité (cela supprimerait tout job absent du manifeste, y compris ceux créés via le dashboard).

Nommez les namespaces d’après des environnements ou des équipes :

# manifests/production.yaml
namespace: production
jobs: [...]

# manifests/staging.yaml
namespace: staging
jobs: [...]

Le dashboard affiche le namespace de chaque job. Les ressources créées via le dashboard (sans namespace) se trouvent dans le namespace par défaut et ne sont jamais touchées par un apply --prune avec namespace.

Plusieurs namespaces dans un monorepo

Organisez un fichier de manifeste par namespace :

manifests/
  production.yaml    # namespace: production
  staging.yaml       # namespace: staging
  workers.yaml       # namespace: workers-team

Appliquez chacun indépendamment :

steadycron apply --prune manifests/production.yaml
steadycron apply --prune manifests/staging.yaml

Identité stable et sécurité du renommage

Chaque ressource d’un manifeste possède un champ id. C’est la clé interne stable — elle ne change jamais, même si vous renommez le name du job.

jobs:
  - id: nightly-backup         # ← stable pour toujours
    name: Nightly database backup (prod)   # ← libre de renommer
    kind: heartbeat
    schedule: "0 2 * * *"

Pourquoi c’est important pour les heartbeats : chaque check de heartbeat possède une URL de ping unique liée à son ID interne. Lorsque vous renommez un job de heartbeat, l’URL de ping est conservée — vous n’avez pas besoin de mettre à jour vos scripts, pipelines CI ou intégrations de monitoring.

Si deux entrées ont le même id, validate rejettera le manifeste.

Secrets et variables {#secrets}

Les secrets ne doivent jamais apparaître littéralement dans le manifeste. SteadyCron fournit deux mécanismes :

1. `${ENV_VAR_NAME}` — substitution d’environnement par la CLI

La CLI les lit depuis l’environnement du processus au moment de l’application et les substitue avant d’envoyer le manifeste à l’API. Fonctionne dans n’importe quel champ.

channels:
  - id: ops-slack
    name: Slack #ops
    kind: slack
    config:
      webhook_url: ${SLACK_WEBHOOK_URL}   # ← la CLI lit depuis l'env au moment de l'application

jobs:
  - id: invoice-job
    kind: http
    url: https://${API_HOST}/jobs/invoices
    headers:
      Authorization: Bearer ${INVOICE_API_KEY}

Dans la CI, définissez-les comme secrets du dépôt et transmettez-les au job :

# GitHub Actions
env:
  STEADYCRON_API_KEY: ${{ secrets.STEADYCRON_API_KEY }}
  SLACK_WEBHOOK_URL:  ${{ secrets.SLACK_WEBHOOK_URL }}
  INVOICE_API_KEY:    ${{ secrets.INVOICE_API_KEY }}

2. `{{template_var}}` — substitution côté serveur

Les variables de gabarit sont résolues par le serveur SteadyCron au moment de l’exécution, pas à l’application. Elles ne fonctionnent que dans les champs de jobs HTTP (url, headers, body) et sont utiles pour des valeurs qui varient par exécution ou sont calculées côté serveur.

jobs:
  - id: data-export
    kind: http
    url: https://api.myapp.com/export/{{date}}
    body: '{"run_id": "{{uuid}}"}'

steadycron export émet automatiquement les deux types d’espaces réservés — le manifeste exporté est sûr à commiter sans nettoyage manuel.