PowerShell

Vos scripts PowerShell, avec l'ordonnancement qui leur a toujours manqué.

Dagu exécute PowerShell, pwsh et cmd.exe comme de simples étapes de workflow : les scripts existants gardent leur forme et gagnent un ordre, des reprises, des journaux par étape et un historique consultable dans un navigateur.

Installer sous WindowsComparatif avec le Planificateur
PowerShell, pwsh et cmd.exe dans le même workflow
Shell choisi par workflow ou par étape
La sortie d'un script alimente le suivant
S'exécute en service Windows
01

Choisir le shell une fois, ou par étape

Un workflow déclare son shell et toutes les étapes en héritent. Sans déclaration, Dagu privilégie PowerShell, puis pwsh, puis cmd.exe, de sorte qu'un workflow écrit sur une machine se comporte de façon prévisible sur une autre.

  • Le shell accepte une chaîne ou un tableau ; la forme tableau évite les problèmes de guillemets avec des arguments comme -NoProfile
  • Une étape capture sa sortie dans une variable nommée, lisible par les étapes suivantes et par les préconditions
  • Les préconditions conditionnent une étape à cette valeur : le redémarrage n'a lieu que si le service est réellement arrêté
Vérifier un service et le redémarrer seulement si nécessaire
# service-health.yaml
schedule: "*/15 * * * *"
max_active_runs: 1
shell: powershell -NoProfile

steps:
  - id: check_service
    run: |
      (Get-Service -Name 'MyAppSvc').Status
    output: SVC_STATUS

  - id: restart_if_stopped
    run: Restart-Service -Name 'MyAppSvc'
    depends: check_service
    preconditions:
      - condition: "${SVC_STATUS}"
        expected: "Stopped"
    retry_policy:
      limit: 2
      interval_sec: 30

mail_on:
  failure: true
02

PowerShell et cmd.exe dans un même workflow

On ne réécrit pas des fichiers batch hérités simplement parce que l'ordonnanceur change. Une étape peut surcharger le shell du workflow, si bien qu'un workflow majoritairement PowerShell appelle toujours le .bat qui fonctionne depuis dix ans.

  • La surcharge de shell se place sous with.shell ; un champ shell nu ne peut pas coexister avec run et le validateur le refuse
  • Pour une liste d'arguments exacte sans interprétation par un shell, utilisez une étape exec structurée avec command et args
  • Les workflows mixtes conservent une planification, un historique et un chemin de notification uniques

Les chemins Windows contiennent des antislashs : privilégiez les scalaires de bloc ou les guillemets simples en YAML. Dans une chaîne entre guillemets doubles, un antislash suivi d'un caractère est une échappement, pas un séparateur de chemin.

PowerShell, cmd et un exec direct dans un fichier
# maintenance.yaml
schedule: "0 3 * * *"
shell: ["powershell", "-NoProfile"]

steps:
  - id: report_disk
    run: Get-PSDrive -PSProvider FileSystem | Out-String
    output: DISK_REPORT

  - id: legacy_job
    run: |
      @echo off
      call C:\ops\legacy\run.bat
    with:
      shell: cmd
    depends: report_disk

  - id: direct_exec
    action: exec
    with:
      command: C:\Windows\System32\cmd.exe
      args:
        - /c
        - echo
        - done
    depends: legacy_job

mail_on:
  failure: true
03

Les scripts multilignes restent lisibles

Une étape peut contenir un bloc de script complet plutôt qu'une seule ligne, ce qui laisse les pipelines et les filtres sous la forme qu'un auteur PowerShell écrirait.

  • Les scalaires de bloc préservent les sauts de ligne : les pipelines répartis sur plusieurs lignes restent intacts
  • retry_policy s'applique à toute l'étape, ce qui convient aux scripts touchant des chemins réseau instables ou des fichiers occupés
  • pwsh et Windows PowerShell se choisissent par nom, donc un hôte disposant des deux exécute chaque workflow sur celui voulu
Un script d'archivage de journaux planifié
# archive-logs.yaml
schedule: "30 1 * * *"
shell: pwsh -NoProfile

steps:
  - id: archive
    run: |
      $cutoff = (Get-Date).AddDays(-30)
      Get-ChildItem -Path 'D:\logs' -Filter *.log |
        Where-Object { $_.LastWriteTime -lt $cutoff } |
        Compress-Archive -DestinationPath 'D:\archive\logs.zip' -Update
    retry_policy:
      limit: 2
      interval_sec: 60

  - id: verify
    run: Test-Path 'D:\archive\logs.zip'
    depends: archive

mail_on:
  failure: true
04

D'où cela s'exécute

La planification n'a d'intérêt que si l'ordonnanceur tourne. L'installateur Windows peut enregistrer Dagu comme service, afin que les workflows démarrent avec la machine et non avec une session ouverte.

  • L'installateur PowerShell enregistre un service Windows via un wrapper WinSW à version figée, vérifiable avec Get-Service
  • Des binaires Windows sont publiés pour amd64, 386 et arm64
  • La console web montre l'historique et la sortie par étape depuis n'importe quel navigateur : vérifier un job ne demande pas de bureau à distance

Windows Server 2019 et ultérieur est la cible sûre. Sur des versions plus anciennes sans AF_UNIX les workflows s'exécutent toujours, mais le socket de statut en direct et de contrôle d'arrêt est indisponible et Dagu journalise un avertissement.

FAQ

Practical questions before adopting

Dois-je réécrire mes scripts en YAML ?

Non. Le YAML décrit quand un script s'exécute, ce dont il dépend et ce qui se passe en cas d'échec. Le script lui-même reste un fichier .ps1, appelé comme le faisait le Planificateur de tâches.

Comment transmettre une valeur d'un script au suivant ?

Donnez un nom de sortie à l'étape productrice et référencez-le dans les étapes suivantes. La même référence fonctionne dans une précondition, ce qui permet d'ignorer une étape sauf si une vérification antérieure a renvoyé une valeur donnée.

Un même workflow peut-il utiliser Windows PowerShell et pwsh ?

Oui. Définissez l'un comme valeur par défaut du workflow et surchargez l'autre sur les étapes concernées. Les deux se sélectionnent par nom d'exécutable.

Pourquoi le validateur refuse-t-il un champ shell sur mon étape ?

Un champ shell nu ne peut pas être combiné avec run dans la même étape. Placez la surcharge sous with.shell. Exécuter dagu validate détecte le problème avant le déclenchement de la planification.

Cela fonctionne-t-il aussi sous Linux ?

Oui. pwsh fonctionne sous Linux et macOS, et la même définition de workflow s'y applique. Seules les étapes appelant cmd.exe ou des cmdlets propres à Windows restent spécifiques à Windows.

Next step

Start with one workflow.

Install Dagu, move one script that runs on cron today into YAML, and decide from a real run history.

Installer sous WindowsComparatif avec le Planificateur