update snakemake workflow template with latest Actions + new features
- latest template update is 3 y ago
- need to update all GH actions workflows
- new features should be in line with upcoming update of the workflow catalog, see https://github.com/snakemake/snakemake-workflow-catalog/issues/31
some suggestions that could be implemented (can also be separate issues + PRs):
- add test data so that WF actually runs in GH linting, formatting, testing
- add more structured requirements for
config/README.md-> for example, for parsing it would be good if people avoid level one headings (# how to use my workflow), because the catalog building will already add workflow name andusagesubsection - add verbose README.md to front page
- add option to deposit a workflow overview image (like a rendered DAG or custom-made road map). An example can be found here. This could be linked in the
.snakemake-workflow-catalog.ymlYAML for example like this:
usage:
...
resources:
workflow_overview: "resources/images/my_dag.svg"
There are some caveats with including external images, for example size for the built catalog could increase, but we could also just include a link to the image as long as it's stored on github.
Our group has a fork of the template that already implements some of these ideas. Can be a starting point?
If you would be willing to work on this, that would be great. Also feel free to simply start a pull request with some of your ideas and gradually add to that. Then we can directly discuss on suggested changes. And I would move this issue over to the snakemake-workflow-template repo, if this is OK.
Here are some initial responses
* need to update all GH actions workflows
Definitely. Feel free to check the GH actions on other snakemake repositories and in the snakemake-workflows organization for inspiration of what a more up to date GH actions workflow might look like. We for example very actively maintain this one:
https://github.com/snakemake-workflows/dna-seq-varlociraptor/blame/master/.github/workflows/main.yml
* new features should be in line with upcoming update of the workflow catalog, see [Suggestions to update the look of the workflow catalog #31](https://github.com/snakemake/snakemake-workflow-catalog/issues/31)
This is why you are the perfect candidate for this task! :D
some suggestions that could be implemented (can also be separate issues + PRs):
* add test data so that WF actually runs in GH linting, formatting, testing
If you can come up with something very minimal, that would be great. But generally, coming up with usable testing data for a workflow is usually up to the workflow developers.
* add more structured requirements for `config/README.md` -> for example, for parsing it would be good if people avoid level one headings (`# how to use my workflow`), because the catalog building will already add workflow name and `usage` subsection
More structure here would definitely be helpful. But requiring users not to use the highest level is probably a bit counter-intuitive. Couldn't the parser simply downgrade everything by a level?
* add verbose README.md to front page
Yes, definitely. I was also thinking if maybe some of the current TODOs could actually be handled by the templating mechanism itself, but I never got around to checking this out. Basically, it would be great if things like parsing in the GitHub user/org and repo names could be parsed into the respective places automatically. This would save a bunch of search-and-replaces...
* add option to deposit a workflow overview image (like a rendered DAG or custom-made road map). An example can be found [here](https://github.com/MPUSP/snakemake-crispr-guides). This could be linked in the `.snakemake-workflow-catalog.yml` YAML for example like this:usage: ... resources: workflow_overview: "resources/images/my_dag.svg"There are some caveats with including external images, for example size for the built catalog could increase, but we could also just include a link to the image as long as it's stored on github. Having visualizations in there is definitely a good idea. Maybe this can be tackled together with working on the visulizations that get generated for the
snakemake --reportfunctionality: https://github.com/snakemake/snakemake/issues/3322
Our group has a fork of the template that already implements some of these ideas. Can be a starting point? Nice. Yes, let's maybe do a pull request from this fork and then work from there.
Thanks for your feedback David! All good points.
Regarding this:
More structure here would definitely be helpful. But requiring users not to use the highest level is probably a bit counter-intuitive. Couldn't the parser simply downgrade everything by a level?
Absolutely, I also thought about this. Probably the easiest fix. For the rest I will make an attempt.
A PR is open and addresses some of these ideas.
merged