Skip to content

docs: Add documentation with example usage #27

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
LKress wants to merge 1 commit into
base: main
Choose a base branch
from
Open

docs: Add documentation with example usage #27

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions docs/further.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@
### Example setup

The cluster generic plugin enables access to workflow variables (such as `rule`, `resources`, or `threads`) within the strings used to define cluster generic plugin arguments.
This makes it possible to create custom configurations for running workflows on various cluster systems that support a submission command accepting the path to a job script. The following example Snakemake profile (see [Profiles](https://snakemake.readthedocs.io/en/stable/executing/cli.html#profiles)) shows this for a custom SLURM execution configuration setup. Submitting jobs with this setup would result in having the rule name of the current job contained in the SLURM job name.

```yaml
executor: cluster-generic
cluster-generic-submit-cmd: sbatch --cpus-per-task {threads} --mem={resources.mem_mb} --job-name=smk-{rule} --parsable
cluster-generic-cancel-cmd: scancel
```
Comment on lines +3 to +10

@coderabbitai coderabbitai Bot Mar 14, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Documentation is still incomplete vs Issue #14 acceptance criteria.

This section adds a good SLURM example, but it does not yet answer the key “how to use” questions from the linked issue: (1) how to adapt for non-Slurm clusters (e.g., LSF), (2) where required resources should be defined, and (3) whether submit/status/cancel commands are configured in profile/config vs CLI. Please add a short subsection that explicitly covers those points so closing #14 is fully justified.

🤖 Prompt for AI Agents 
Verify each finding against the current code and only fix it if needed.

In `@docs/further.md` around lines 3 - 10, Add a new short subsection under the
cluster generic plugin docs that explicitly answers the three acceptance points:
explain that the cluster-generic executor is adapter-agnostic and show how to
replace the example "sbatch" command with other schedulers (mention LSF's "bsub"
as an example) while keeping the {threads}/{resources.mem_mb}/{rule}
placeholders; state that required resources should be declared in the Snakemake
rule blocks (resources: mem_mb: ..., threads: ...) and referenced from the
profile via cluster-generic-submit-cmd placeholders; and clarify configuration
precedence by saying submit/status/cancel commands (cluster-generic-submit-cmd,
cluster-generic-cancel-cmd and any status command) are typically set in the
profile or config.yaml for reproducibility but can be overridden on the CLI,
referencing the executor: cluster-generic entry and the three cluster-generic-*
keys so readers know exactly where to change them.


2 changes: 2 additions & 0 deletions docs/intro.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,2 @@
The cluster generic plugin allows submitting jobs to cluster systems that provide a submission command that accepts the path to a job script.

Loading