|
1 | 1 | # nf-core/nascent: Contributing Guidelines
|
2 | 2 |
|
3 |
| -Hi there! Many thanks for taking an interest in improving nf-core/nascent. |
| 3 | +Hi there! |
| 4 | +Many thanks for taking an interest in improving nf-core/nascent. |
4 | 5 |
|
5 |
| -We try to manage the required tasks for nf-core/nascent 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/nascent 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/nascent 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/nascent then the best place to ask is on the nf-core Slack [#nascent](https://nfcore.slack.com/channels/nascent) 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/nascent, 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/nascent issues](https://github.com/nf-core/nascent/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/nascent repository](https://github.com/nf-core/nascent) 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/nascent, 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/nascent issues](https://github.com/nf-core/nascent/issues) to avoid duplicating work. If there isn't one already, please create one so that others know you're working on this |
| 19 | +2. [Fork](https://help.github.com/en/github/getting-started-with-github/fork-a-repo) the [nf-core/nascent repository](https://github.com/nf-core/nascent) to your GitHub account |
| 20 | +3. Make the necessary changes / additions within your forked repository following [Pipeline conventions](#pipeline-contribution-conventions) |
| 21 | +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). |
| 22 | +5. Submit a Pull Request against the `dev` branch and wait for the code to be reviewed and merged |
24 | 23 |
|
| 24 | +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 | 25 |
|
26 | 26 | ## Tests
|
27 |
| -When you create a pull request with changes, [Travis CI](https://travis-ci.org/) will run automatic tests. |
| 27 | + |
| 28 | +When you create a pull request with changes, [GitHub Actions](https://github.com/features/actions) will run automatic tests. |
28 | 29 | Typically, pull-requests are only fully reviewed when these tests are passing, though of course we can help out before then.
|
29 | 30 |
|
30 | 31 | There are typically two types of tests that run:
|
31 | 32 |
|
32 |
| -### Lint Tests |
33 |
| -The nf-core has a [set of guidelines](http://nf-co.re/guidelines) which all pipelines must adhere to. |
| 33 | +### Lint tests |
| 34 | + |
| 35 | +`nf-core` has a [set of guidelines](https://nf-co.re/developers/guidelines) which all pipelines must adhere to. |
34 | 36 | 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 | 37 |
|
36 | 38 | If any failures or warnings are encountered, please follow the listed URL for more documentation.
|
37 | 39 |
|
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. |
| 40 | +### Pipeline tests |
| 41 | + |
| 42 | +Each `nf-core` pipeline should be set up with a minimal set of test-data. |
| 43 | +`GitHub Actions` then runs the pipeline on this data to ensure that it exits successfully. |
41 | 44 | 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. |
| 45 | +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 | + |
| 47 | +## Patch |
| 48 | + |
| 49 | +:warning: Only in the unlikely and regretful event of a release happening with a bug. |
| 50 | + |
| 51 | +- On your own fork, make a new branch `patch` based on `upstream/master`. |
| 52 | +- Fix the bug, and bump version (X.Y.Z+1). |
| 53 | +- A PR should be made on `master` from patch to directly this particular bug. |
43 | 54 |
|
44 | 55 | ## Getting help
|
45 |
| -For further information/help, please consult the [nf-core/nascent documentation](https://github.com/nf-core/nascent#documentation) and don't hesitate to get in touch on the pipeline channel on [Slack](https://nf-core-invite.herokuapp.com/). |
| 56 | + |
| 57 | +For further information/help, please consult the [nf-core/nascent documentation](https://nf-co.re/nascent/usage) and don't hesitate to get in touch on the nf-core Slack [#nascent](https://nfcore.slack.com/channels/nascent) channel ([join our Slack here](https://nf-co.re/join/slack)). |
| 58 | + |
| 59 | +## Pipeline contribution conventions |
| 60 | + |
| 61 | +To make the nf-core/nascent 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. |
| 62 | + |
| 63 | +### Adding a new step |
| 64 | + |
| 65 | +If you wish to contribute a new step, please use the following coding standards: |
| 66 | + |
| 67 | +1. Define the corresponding input channel into your new process from the expected previous process channel |
| 68 | +2. Write the process block (see below). |
| 69 | +3. Define the output channel if needed (see below). |
| 70 | +4. Add any new parameters to `nextflow.config` with a default (see below). |
| 71 | +5. Add any new parameters to `nextflow_schema.json` with help text (via the `nf-core schema build` tool). |
| 72 | +6. Add sanity checks and validation for all relevant parameters. |
| 73 | +7. Perform local tests to validate that the new code works as expected. |
| 74 | +8. If applicable, add a new test command in `.github/workflow/ci.yml`. |
| 75 | +9. Update MultiQC config `assets/multiqc_config.yml` so relevant suffixes, file name clean up and module plots are in the appropriate order. If applicable, add a [MultiQC](https://https://multiqc.info/) module. |
| 76 | +10. Add a description of the output files and if relevant any appropriate images from the MultiQC report to `docs/output.md`. |
| 77 | + |
| 78 | +### Default values |
| 79 | + |
| 80 | +Parameters should be initialised / defined with default values in `nextflow.config` under the `params` scope. |
| 81 | + |
| 82 | +Once there, use `nf-core schema build` to add to `nextflow_schema.json`. |
| 83 | + |
| 84 | +### Default processes resource requirements |
| 85 | + |
| 86 | +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. |
| 87 | + |
| 88 | +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. |
| 89 | + |
| 90 | +### Naming schemes |
| 91 | + |
| 92 | +Please use the following naming schemes, to make it easy to understand what is going where. |
| 93 | + |
| 94 | +- initial process channel: `ch_output_from_<process>` |
| 95 | +- intermediate and terminal channels: `ch_<previousprocess>_for_<nextprocess>` |
| 96 | + |
| 97 | +### Nextflow version bumping |
| 98 | + |
| 99 | +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]` |
| 100 | + |
| 101 | +### Images and figures |
| 102 | + |
| 103 | +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