PowerShell

आपकी PowerShell स्क्रिप्ट, उस शेड्यूलिंग के साथ जो उन्हें कभी नहीं मिली।

Dagu, PowerShell, pwsh और cmd.exe को सामान्य वर्कफ़्लो चरणों की तरह चलाता है, इसलिए मौजूदा स्क्रिप्ट अपने रूप में बनी रहती हैं और उन्हें क्रम, पुनःप्रयास, प्रति-चरण लॉग तथा ब्राउज़र में खुलने वाला रन इतिहास मिल जाता है।

Windows पर इंस्टॉल करेंTask Scheduler से तुलना
एक ही वर्कफ़्लो में PowerShell, pwsh और cmd.exe
शेल प्रति वर्कफ़्लो या प्रति चरण चुनें
एक स्क्रिप्ट का आउटपुट अगली को मिलता है
Windows सेवा के रूप में चलता है
01

शेल एक बार चुनें, या प्रति चरण

वर्कफ़्लो अपना शेल घोषित करता है और सभी चरण उसे विरासत में लेते हैं। घोषित न होने पर Dagu पहले PowerShell, फिर pwsh, फिर cmd.exe को प्राथमिकता देता है, इसलिए एक मशीन पर लिखा वर्कफ़्लो दूसरी पर भी अनुमानित रूप से चलता है।

  • शेल स्ट्रिंग या ऐरे दोनों स्वीकार करता है; -NoProfile जैसे तर्कों की कोटिंग समस्या ऐरे रूप से टलती है
  • चरण अपना आउटपुट नामित वेरिएबल में लेता है, जिसे बाद के चरण और पूर्वशर्तें पढ़ सकती हैं
  • पूर्वशर्तें उसी मान पर चरण को नियंत्रित करती हैं, इसलिए पुनःआरंभ तभी होता है जब सेवा वास्तव में रुकी हो
सेवा जाँचें और आवश्यक होने पर ही पुनःआरंभ करें
# 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 और cmd.exe

शेड्यूलर बदलने भर से पुरानी बैच फ़ाइलें शायद ही दोबारा लिखी जाती हैं। चरण वर्कफ़्लो के शेल को ओवरराइड कर सकता है, इसलिए मुख्यतः PowerShell वाला वर्कफ़्लो भी दस साल से चल रही .bat को बुला सकता है।

  • चरण पर शेल ओवरराइड with.shell में लिखें; अकेला shell फ़ील्ड run के साथ नहीं चल सकता और वैलिडेटर उसे अस्वीकार करता है
  • बिना किसी शेल पार्सिंग के सटीक तर्क सूची के लिए command और args वाला संरचित exec चरण उपयोग करें
  • मिश्रित वर्कफ़्लो में शेड्यूल, इतिहास और सूचना मार्ग एक ही रहते हैं

Windows पथों में बैकस्लैश होते हैं, इसलिए YAML में ब्लॉक स्केलर या सिंगल कोट को प्राथमिकता दें। डबल-कोटेड स्ट्रिंग में बैकस्लैश के बाद आने वाला अक्षर एस्केप होता है, पथ विभाजक नहीं।

एक फ़ाइल में PowerShell, cmd और सीधा exec
# 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

बहु-पंक्ति स्क्रिप्ट पठनीय बनी रहती हैं

चरण एक पंक्ति के बजाय पूरा स्क्रिप्ट ब्लॉक रख सकता है, जिससे पाइपलाइन और फ़िल्टर उसी रूप में रहते हैं जैसे PowerShell लिखने वाला लिखता है।

  • ब्लॉक स्केलर पंक्ति-विराम बनाए रखते हैं, इसलिए कई पंक्तियों में बँटी पाइपलाइन ज्यों की त्यों रहती है
  • retry_policy पूरे चरण पर लागू होती है, जो अस्थिर नेटवर्क पथ या व्यस्त फ़ाइलों को छूने वाली स्क्रिप्ट के लिए उपयुक्त है
  • pwsh और Windows PowerShell नाम से चुने जाते हैं, इसलिए दोनों वाले होस्ट पर हर वर्कफ़्लो इच्छित पर चलता है
निर्धारित समय पर लॉग संग्रह स्क्रिप्ट
# 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

यह कहाँ से चलता है

शेड्यूलिंग तभी काम की है जब शेड्यूलर चल रहा हो। Windows इंस्टॉलर Dagu को सेवा के रूप में पंजीकृत कर सकता है, जिससे वर्कफ़्लो लॉगिन सत्र के बजाय मशीन के साथ शुरू होते हैं।

  • PowerShell इंस्टॉलर वर्शन-पिन किए WinSW रैपर से Windows सेवा पंजीकृत करता है, जिसे Get-Service से जाँचा जा सकता है
  • Windows बिल्ड amd64, 386 और arm64 के लिए प्रकाशित होते हैं
  • वेब कंसोल किसी भी ब्राउज़र से रन इतिहास और प्रति-चरण आउटपुट दिखाता है, इसलिए जॉब देखने के लिए रिमोट डेस्कटॉप ज़रूरी नहीं

Windows Server 2019 और बाद का संस्करण सुरक्षित लक्ष्य है। AF_UNIX रहित पुराने बिल्ड पर वर्कफ़्लो चलते तो हैं, पर लाइव स्थिति और स्टॉप-कंट्रोल सॉकेट उपलब्ध नहीं होता और Dagu चेतावनी दर्ज करता है।

FAQ

Practical questions before adopting

क्या मुझे स्क्रिप्ट को YAML में दोबारा लिखना होगा?

नहीं। YAML यह बताता है कि स्क्रिप्ट कब चलेगी, किस पर निर्भर है और विफल होने पर क्या होगा। स्क्रिप्ट स्वयं .ps1 फ़ाइल ही रहती है और उसी तरह बुलाई जाती है जैसे Task Scheduler बुलाता था।

एक स्क्रिप्ट का मान अगली को कैसे भेजें?

उत्पादक चरण को आउटपुट नाम दें और बाद के चरणों में उसका संदर्भ दें। वही संदर्भ पूर्वशर्त में भी काम करता है, जिससे पिछली जाँच का विशेष मान न आने पर चरण छोड़ा जा सकता है।

क्या एक वर्कफ़्लो में Windows PowerShell और pwsh दोनों चल सकते हैं?

हाँ। एक को वर्कफ़्लो का डिफ़ॉल्ट बनाएँ और आवश्यक चरणों पर दूसरे से ओवरराइड करें। दोनों निष्पादन फ़ाइल के नाम से चुने जाते हैं।

मेरे चरण पर shell फ़ील्ड वैलिडेटर क्यों अस्वीकार करता है?

अकेला shell फ़ील्ड उसी चरण के run के साथ नहीं चल सकता। ओवरराइड को with.shell के नीचे रखें। dagu validate चलाने पर यह शेड्यूल चलने से पहले पकड़ में आ जाता है।

क्या यह Linux पर भी काम करता है?

हाँ। pwsh Linux और macOS पर चलता है और वही वर्कफ़्लो परिभाषा वहाँ भी काम करती है। केवल वे चरण Windows-विशिष्ट रहते हैं जो cmd.exe या Windows-only cmdlet बुलाते हैं।

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.

Windows पर इंस्टॉल करेंTask Scheduler से तुलना