|
1 | 1 | # nf-core/bactmap: Contributing Guidelines
|
2 | 2 |
|
3 |
| -Hi there! Many thanks for taking an interest in improving nf-core/bactmap. |
| 3 | +Hi there! |
| 4 | +Many thanks for taking an interest in improving nf-core/bactmap. |
4 | 5 |
|
5 |
| -We try to manage the required tasks for nf-core/bactmap using GitHub issues, you probably came to this page when creating one. Please use the pre-filled template to save time. |
| 6 | +We try to manage the required tasks for nf-core/bactmap using GitHub issues, you probably came to this page when creating one. |
| 7 | +Please use the pre-filled template to save time. |
6 | 8 |
|
7 |
| -However, don't be put off by this template - other more general issues and suggestions are welcome! Contributions to the code are even more welcome ;) |
| 9 | +However, don't be put off by this template - other more general issues and suggestions are welcome! |
| 10 | +Contributions to the code are even more welcome ;) |
8 | 11 |
|
9 |
| -> If you need help using or modifying nf-core/bactmap then the best place to go is the Gitter chatroom where you can ask us questions directly: https://gitter.im/nf-core/Lobby |
| 12 | +> If you need help using or modifying nf-core/bactmap then the best place to ask is on the nf-core Slack [#bactmap](https://nfcore.slack.com/channels/bactmap) channel ([join our Slack here](https://nf-co.re/join/slack)). |
10 | 13 |
|
11 | 14 | ## Contribution workflow
|
12 |
| -If you'd like to write some code for nf-core/bactmap, the standard workflow |
13 |
| -is as follows: |
14 | 15 |
|
15 |
| -1. Check that there isn't already an issue about your idea in the |
16 |
| - [nf-core/bactmap issues](https://github.com/nf-core/bactmap/issues) to avoid |
17 |
| - duplicating work. |
18 |
| - * If there isn't one already, please create one so that others know you're working on this |
19 |
| -2. Fork the [nf-core/bactmap repository](https://github.com/nf-core/bactmap) to your GitHub account |
20 |
| -3. Make the necessary changes / additions within your forked repository |
21 |
| -4. Submit a Pull Request against the `dev` branch and wait for the code to be reviewed and merged. |
| 16 | +If you'd like to write some code for nf-core/bactmap, the standard workflow is as follows: |
22 | 17 |
|
23 |
| -If you're not used to this workflow with git, you can start with some [basic docs from GitHub](https://help.github.com/articles/fork-a-repo/) or even their [excellent interactive tutorial](https://try.github.io/). |
| 18 | +1. Check that there isn't already an issue about your idea in the [nf-core/bactmap issues](https://github.com/nf-core/bactmap/issues) to avoid duplicating work |
| 19 | + * If there isn't one already, please create one so that others know you're working on this |
| 20 | +2. [Fork](https://help.github.com/en/github/getting-started-with-github/fork-a-repo) the [nf-core/bactmap repository](https://github.com/nf-core/bactmap) to your GitHub account |
| 21 | +3. Make the necessary changes / additions within your forked repository following [Pipeline conventions](#pipeline-contribution-conventions) |
| 22 | +4. Use `nf-core schema build .` and add any new parameters to the pipeline JSON schema (requires [nf-core tools](https://github.com/nf-core/tools) >= 1.10). |
| 23 | +5. Submit a Pull Request against the `dev` branch and wait for the code to be reviewed and merged |
24 | 24 |
|
| 25 | +If you're not used to this workflow with git, you can start with some [docs from GitHub](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests) or even their [excellent `git` resources](https://try.github.io/). |
25 | 26 |
|
26 | 27 | ## Tests
|
27 |
| -When you create a pull request with changes, [Travis CI](https://travis-ci.org/) will run automatic tests. |
| 28 | + |
| 29 | +When you create a pull request with changes, [GitHub Actions](https://github.com/features/actions) will run automatic tests. |
28 | 30 | Typically, pull-requests are only fully reviewed when these tests are passing, though of course we can help out before then.
|
29 | 31 |
|
30 | 32 | There are typically two types of tests that run:
|
31 | 33 |
|
32 |
| -### Lint Tests |
33 |
| -The nf-core has a [set of guidelines](http://nf-co.re/guidelines) which all pipelines must adhere to. |
| 34 | +### Lint tests |
| 35 | + |
| 36 | +`nf-core` has a [set of guidelines](https://nf-co.re/developers/guidelines) which all pipelines must adhere to. |
34 | 37 | To enforce these and ensure that all pipelines stay in sync, we have developed a helper tool which runs checks on the pipeline code. This is in the [nf-core/tools repository](https://github.com/nf-core/tools) and once installed can be run locally with the `nf-core lint <pipeline-directory>` command.
|
35 | 38 |
|
36 | 39 | If any failures or warnings are encountered, please follow the listed URL for more documentation.
|
37 | 40 |
|
38 |
| -### Pipeline Tests |
39 |
| -Each nf-core pipeline should be set up with a minimal set of test-data. |
40 |
| -Travis CI then runs the pipeline on this data to ensure that it exists successfully. |
| 41 | +### Pipeline tests |
| 42 | + |
| 43 | +Each `nf-core` pipeline should be set up with a minimal set of test-data. |
| 44 | +`GitHub Actions` then runs the pipeline on this data to ensure that it exits successfully. |
41 | 45 | If there are any failures then the automated tests fail.
|
42 |
| -These tests are run both with the latest available version of Nextflow and also the minimum required version that is stated in the pipeline code. |
| 46 | +These tests are run both with the latest available version of `Nextflow` and also the minimum required version that is stated in the pipeline code. |
| 47 | + |
| 48 | +## Patch |
| 49 | + |
| 50 | +:warning: Only in the unlikely and regretful event of a release happening with a bug. |
| 51 | + |
| 52 | +* On your own fork, make a new branch `patch` based on `upstream/master`. |
| 53 | +* Fix the bug, and bump version (X.Y.Z+1). |
| 54 | +* A PR should be made on `master` from patch to directly this particular bug. |
43 | 55 |
|
44 | 56 | ## Getting help
|
45 |
| -For further information/help, please consult the [nf-core/bactmap documentation](https://github.com/nf-core/bactmap#documentation) and don't hesitate to get in touch on [Gitter](https://gitter.im/nf-core/Lobby) |
| 57 | + |
| 58 | +For further information/help, please consult the [nf-core/bactmap documentation](https://nf-co.re/bactmap/usage) and don't hesitate to get in touch on the nf-core Slack [#bactmap](https://nfcore.slack.com/channels/bactmap) channel ([join our Slack here](https://nf-co.re/join/slack)). |
| 59 | + |
| 60 | +## Pipeline contribution conventions |
| 61 | + |
| 62 | +To make the nf-core/bactmap code and processing logic more understandable for new contributors and to ensure quality, we semi-standardise the way the code and other contributions are written. |
| 63 | + |
| 64 | +### Adding a new step |
| 65 | + |
| 66 | +If you wish to contribute a new step, please use the following coding standards: |
| 67 | + |
| 68 | +1. Define the corresponding input channel into your new process from the expected previous process channel |
| 69 | +2. Write the process block (see below). |
| 70 | +3. Define the output channel if needed (see below). |
| 71 | +4. Add any new flags/options to `nextflow.config` with a default (see below). |
| 72 | +5. Add any new flags/options to `nextflow_schema.json` with help text (with `nf-core schema build .`). |
| 73 | +6. Add any new flags/options to the help message (for integer/text parameters, print to help the corresponding `nextflow.config` parameter). |
| 74 | +7. Add sanity checks for all relevant parameters. |
| 75 | +8. Add any new software to the `scrape_software_versions.py` script in `bin/` and the version command to the `scrape_software_versions` process in `main.nf`. |
| 76 | +9. Do local tests that the new code works properly and as expected. |
| 77 | +10. Add a new test command in `.github/workflow/ci.yml`. |
| 78 | +11. If applicable add a [MultiQC](https://https://multiqc.info/) module. |
| 79 | +12. Update MultiQC config `assets/multiqc_config.yaml` so relevant suffixes, name clean up, General Statistics Table column order, and module figures are in the right order. |
| 80 | +13. Optional: Add any descriptions of MultiQC report sections and output files to `docs/output.md`. |
| 81 | + |
| 82 | +### Default values |
| 83 | + |
| 84 | +Parameters should be initialised / defined with default values in `nextflow.config` under the `params` scope. |
| 85 | + |
| 86 | +Once there, use `nf-core schema build .` to add to `nextflow_schema.json`. |
| 87 | + |
| 88 | +### Default processes resource requirements |
| 89 | + |
| 90 | +Sensible defaults for process resource requirements (CPUs / memory / time) for a process should be defined in `conf/base.config`. These should generally be specified generic with `withLabel:` selectors so they can be shared across multiple processes/steps of the pipeline. A nf-core standard set of labels that should be followed where possible can be seen in the [nf-core pipeline template](https://github.com/nf-core/tools/blob/master/nf_core/pipeline-template/conf/base.config), which has the default process as a single core-process, and then different levels of multi-core configurations for increasingly large memory requirements defined with standardised labels. |
| 91 | + |
| 92 | +The process resources can be passed on to the tool dynamically within the process with the `${task.cpu}` and `${task.memory}` variables in the `script:` block. |
| 93 | + |
| 94 | +### Naming schemes |
| 95 | + |
| 96 | +Please use the following naming schemes, to make it easy to understand what is going where. |
| 97 | + |
| 98 | +* initial process channel: `ch_output_from_<process>` |
| 99 | +* intermediate and terminal channels: `ch_<previousprocess>_for_<nextprocess>` |
| 100 | + |
| 101 | +### Nextflow version bumping |
| 102 | + |
| 103 | +If you are using a new feature from core Nextflow, you may bump the minimum required version of nextflow in the pipeline with: `nf-core bump-version --nextflow . [min-nf-version]` |
| 104 | + |
| 105 | +### Software version reporting |
| 106 | + |
| 107 | +If you add a new tool to the pipeline, please ensure you add the information of the tool to the `get_software_version` process. |
| 108 | + |
| 109 | +Add to the script block of the process, something like the following: |
| 110 | + |
| 111 | +```bash |
| 112 | +<YOUR_TOOL> --version &> v_<YOUR_TOOL>.txt 2>&1 || true |
| 113 | +``` |
| 114 | + |
| 115 | +or |
| 116 | + |
| 117 | +```bash |
| 118 | +<YOUR_TOOL> --help | head -n 1 &> v_<YOUR_TOOL>.txt 2>&1 || true |
| 119 | +``` |
| 120 | + |
| 121 | +You then need to edit the script `bin/scrape_software_versions.py` to: |
| 122 | + |
| 123 | +1. Add a Python regex for your tool's `--version` output (as in stored in the `v_<YOUR_TOOL>.txt` file), to ensure the version is reported as a `v` and the version number e.g. `v2.1.1` |
| 124 | +2. Add a HTML entry to the `OrderedDict` for formatting in MultiQC. |
| 125 | + |
| 126 | +### Images and figures |
| 127 | + |
| 128 | +For overview images and other documents we follow the nf-core [style guidelines and examples](https://nf-co.re/developers/design_guidelines). |
0 commit comments