Run Reproducible Batch Jobs from One JSON Config

• →List every job in one JSON --config — generate, verify, duplicates, mixed freely.
• →Run them all with foldermanifest --config jobs.json.
• →The batch returns the worst exit code — one pass/fail signal.
• →It is data, not code — reviewable in a pull request, identical everywhere.

Why a config beats a script

The natural way to automate several folders is a batch file with one command per line. It works — until the quoting drifts, a path with a space breaks on one machine, and nobody can tell what the script actually checks without reading it line by line. A --config file is the boring, durable alternative: it’s data, not code.

With the FolderManifest CLI, a single JSON file describes every job. There’s no shell to escape, the same file runs identically on every machine, and a teammate can review it in a pull request the way they’d review config — because that’s what it is.

Anatomy of a config file

The file is a jobs array. Each entry names a cmd, the paths it acts on, and that command’s own flags. Different command types live happily in the same config:

{
  "jobs": [
    { "cmd": "verify",     "paths": ["C:\\Backups\\Invoices"],  "manifest": "D:\\baselines\\invoices.json" },
    { "cmd": "verify",     "paths": ["C:\\Backups\\Contracts"], "manifest": "D:\\baselines\\contracts.json" },
    { "cmd": "generate",   "paths": ["C:\\Deliverables\\2026"],  "format": "json", "out": "D:\\baselines\\deliverables-2026" },
    { "cmd": "duplicates", "paths": ["E:\\Media"],                 "report": "D:\\reports\\media-dupes" }
  ]
}

This one config verifies two backups against their baselines, refreshes a manifest for the current deliverables, and produces a duplicate report for a media drive — in a single, reviewable place.

Job fields reference

Every job is an object. cmd and paths are the constants; the rest mirror the command-line flags for that command:

Running the batch

One command runs every job in order:

foldermanifest --config jobs.json

Add --json for machine-readable per-job results you can pipe into a log or a dashboard. The jobs run top to bottom, each with its own flags exactly as if you’d typed them by hand.

One exit code for the whole run

A batch is only useful if you can act on its result without parsing pages of output. FolderManifest collapses the run to a single exit code — the worst outcome among the jobs:

So your scheduler or pipeline line stays trivial: run the config, and branch on non-zero. A clean run is silent; a problem run is one alert.

Schedule it on Windows

To run the batch every night, point a Windows Task Scheduler job at the config command from an elevated Command Prompt:

schtasks /Create ^
  /TN "FolderManifest Nightly Batch" ^
  /TR "foldermanifest --config C:\ops\jobs.json" ^
  /SC DAILY /ST 02:00 /RL HIGHEST /F

The full Task Scheduler walkthrough — including running unattended with no one logged in — is in the automate folder verification guide.

Wiring it into CI

Because the exit code already means pass/fail, a CI step needs no extra glue. Drop the config into the repo and call it — the build fails automatically when a generated artifact drifts from its baseline:

- name: Verify generated artifacts
  run: foldermanifest --config ci/integrity-jobs.json --json

Same file, same behaviour as your scheduled job — which is the whole point. A drift gate that catches unexpected changes before deploy is also covered in the CI/CD checksum validation guide.

Make it version-controlled

The real payoff is treating these routines like the infrastructure they are. Commit jobs.json to your ops repo and every change is reviewed, every machine runs the identical routine, and “what do we check?” has a single, diffable answer. Need to watch a new folder? Add three lines, open a pull request — not a new scheduled task on a server nobody remembers.

The full flag reference for every command lives in the CLI documentation.