Crewster
HPC cluster workflow automation - sync files to remote cluster, submit scheduler jobs (Slurm/PJM), and monitor job status. Use when working with crewster.toml, submitting HPC jobs, syncing to clusters, or checking job status.From its SKILL.md
npx -y skills add ultimatile/crewster --skill crewsterAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
3.8 KB, as published. Nobody here has run it
crewster CLI
HPC workflow automation tool for file sync and scheduler job management (Slurm/PJM).
CLI Reference
!`crewster --skill`
Getting Started
If crewster.toml does not exist in the project, run crewster init to create it, then ask the user to edit it with their cluster settings (host, workdir, scheduler, etc.) before proceeding.
Typical Workflow
crewster sync- Sync files to remote cluster (--dry-runto preview)crewster exec "command"- Run setup on the login node (package installs, configure, etc.)crewster submit "command"orcrewster submit -s script.sh- Submit a jobcrewster status <id>- Check job status (accepts run_id or job_id)crewster job-output <id>- View stdout (-efor stderr)crewster wait <id>- Wait for completion
Key Concepts
- Project root: crewster walks up from CWD to find
crewster.toml(like git finds.git). All commands work from any subdirectory.--project-dir <path>overrides the derived project root (for configs kept outside the working tree); it requires an explicit config (--configor$CREWSTER_CONFIG), and metadata-reading commands (status,list,job-output,wait) must be re-invoked with the same--project-dirthe run was submitted with. - run_id vs job_id:
crewster submitreturns both. Either can be used withstatus,job-output,wait. - Default working directory:
crewster submitruns the job with its PWD set to the resolved[cluster].workdirfromcrewster.toml. Scripts passed via-stherefore do not need tocdto the project root — they start there. Adding a manualcd(or relying on$SLURM_SUBMIT_DIR, which may not be propagated to the job's environment) can move the job to the wrong directory. - Multi-setup runs: Submit from subdirectories to set the job's remote working directory accordingly (e.g.,
cd runs/setup-a && crewster submit "python main.py"runs in/remote/project/runs/setup-a). - Config resolution:
--config/-c(given after the subcommand, e.g.crewster sync -c ~/my.toml) >$CREWSTER_CONFIG> walk-up discovery >./crewster.toml. A legacy$HPC_CONFIG/hpc.tomlis still read as a deprecated fallback (prints a warning; removed in v1.0). - Sync scope:
crewster syncalways syncs the entire project root (the--project-diroverride when given), regardless of CWD.
Writing scripts for crewster submit -s
- Start from the assumption that PWD is already
[cluster].workdir. Nocdneeded for the common case. - If you genuinely need a different working directory, prefer an explicit absolute path or a
WORKDIRenv-var override; do not rely on$SLURM_SUBMIT_DIR(the scheduler does not always propagate it into the job's shell env). - The script's stdout/stderr land in the scheduler's job-output files, retrievable via
crewster job-output <id>. #SBATCH/#PJMdirectives at the top of the script (column-zero, before the first executable line) are honored: crewster hoists them into the rendered job-script prologue. On conflict with the corresponding config entry ([slurm.options]for Slurm, thepjm.optionsarray for PJM), the script's value wins.
Common pitfalls
- Adding
cd "$HOME/path/to/project"to a submitted script: The job already starts in workdir; the manualcdis redundant and silently incorrect if the path doesn't exactly match the deployed one. - Hardcoding deployment-specific paths in repo-tracked scripts: Use a
WORKDIRenv override or script-relative resolution; deployment paths belong increwster.toml, not script source.