| title | Contributing |
|---|---|
| markdownPlugin | checklist |
Hi there! Thanks for taking an interest in improving {{ name }}.
This page describes the recommended nf-core way to contribute to both {{ name }} and nf-core pipelines in general, including:
- General contribution guidelines: common procedures or guides across all nf-core pipelines.
- Pipeline-specific contribution guidelines: procedures or guides specific to the development conventions of {{ name }}.
{% if is_nfcore -%}
Note
If you need help using or modifying {{ name }}, ask on the nf-core Slack [#{{ short_name }}](https://nfcore.slack.com/channels/{{ short_name }}) channel (join our Slack here).
{% endif -%}
To contribute code to any nf-core pipeline:
- Ensure you have Nextflow, nf-core tools, and nf-test installed. See the nf-core/tools repository for instructions.
- Check whether a GitHub [issue](https://github.com/{{ name }}/issues) about your idea already exists. If an issue does not exist, create one so that others are aware you are working on it.
- Fork the [{{ name }} repository](https://github.com/{{ name }}) to your GitHub account.
- Create a branch on your forked repository and make your changes following pipeline conventions (if applicable).
- To fix major bugs, name your branch
patchand follow the patch release process. - Update relevant documentation within the
docs/folder, use nf-core/tools to updatenextflow_schema.json, and updateCITATIONS.md. - Run and/or update tests. See Testing for more information.
- Lint your code with nf-core/tools.
- Submit a pull request (PR) against the
devbranch and request a review.
If you are not used to this workflow with Git, see the GitHub documentation or Git resources for more information.
{% if is_nfcore -%}
For further information and help, see the [{{ name }} documentation](https://nf-co.re/{{ short_name }}/usage) or ask on the nf-core [#{{ short_name }}](https://nfcore.slack.com/channels/{{ short_name }}) Slack channel (join our Slack here). {%- endif %}
{%if codespaces -%}
You can contribute to {{ name }} without installing a local development environment on your machine by using GitHub Codespaces.
GitHub Codespaces is an online developer environment that runs in your browser, complete with VS Code and a terminal. Most nf-core repositories include a devcontainer configuration, which creates a GitHub Codespaces environment specifically for Nextflow development. The environment includes pre-installed nf-core tools, Nextflow, and a few other helpful utilities via a Docker container.
To get started, open the repository in [Codespaces](https://github.com/{{ name }}/codespaces). {%- endif %}
{% if test_config -%}
Once you have made your changes, run the pipeline with nf-test to test them locally.
For additional information, use the --verbose flag to view the Nextflow console log output.
nf-test test --tag test --profile +docker --verboseIf you have added new functionality, ensure you update the test assertions in the .nf.test files in the tests/ directory.
Update the snapshots with the following command:
nf-test test --tag test --profile +docker --verbose --update-snapshots{% endif -%}
When you create a pull request with changes, GitHub Actions will run automatic tests. Pull requests are typically reviewed when these tests are passing.
{% if test_config %}Two types of tests are typically run:{% endif %}
nf-core has a set of guidelines which all pipelines must follow. To enforce these, run linting with nf-core/tools:
nf-core pipelines lint <pipeline_directory>If you encounter failures or warnings, follow the linked documentation printed to screen. For more information about linting tests, see nf-core/tools API documentation.
{%- if test_config %}
Each nf-core pipeline should be set up with a minimal set of test data. GitHub Actions runs the pipeline on this data to ensure it runs through and exits successfully. If there are any failures then the automated tests fail. These tests are run with the latest available version of Nextflow and the minimum required version specified in the pipeline code. {%- endif %}
Warning
Only in the unlikely event of a release that contains a critical bug.
- Create a new branch
patchon your fork based onupstream/mainorupstream/master. - Fix the bug and use nf-core/tools to bump the version to the next semantic version, for example,
1.2.3→1.2.4. - Open a Pull Request from
patchdirectly tomain/masterwith the changes.
nf-core semi-standardises how you write code and other contributions to make the {{ name }} code and processing logic more understandable for new contributors and to ensure quality.
To contribute a new step to the pipeline, follow the general nf-core coding procedure. Please also refer to the pipeline-specific contribution guidelines:
- Define the corresponding input channel into your new process from the expected previous process channel.
- Install a module with nf-core/tools, or write a local module (see default processes resource requirements), and add it to the target
<workflow>.nf. - Define the output channel if needed. Mix the version output channel into
ch_versionsand relevant files intoch_multiqc. - Add new or updated parameters to
nextflow.configwith a default value. - Add new or updated parameters and relevant help text to
nextflow_schema.jsonwith nf-core/tools. - Add validation for relevant parameters to the pipeline utilisation section of
utils_nfcore_{{ shortname }}\_pipeline/main.nfsubworkflow. - Perform local tests to validate that the new code works as expected.
- If applicable, add a new test in the
testsdirectory.
- If applicable, add a new test in the
- Update
usage.md,output.md, andcitation.mdas appropriate. - Lint the code with nf-core/tools.
- Update any diagrams or pipeline images as necessary. {%- if multiqc %}
- Update MultiQC config
assets/multiqc_config.ymlso relevant suffixes, file name cleanup, and module plots are in the appropriate order. - If applicable, create a MultiQC module.
- Add a description of the output files and, if relevant, images from the MultiQC report to
docs/output.md. {%- endif %}
To update the minimum required Nextflow version, see the Nextflow version bumping section below. For more information about pipeline contributions, see pipeline-specific contribution guidelines.
Use the following naming schemes for channels to make the channel flow easier to understand:
- Initial process channel:
ch_output_from_<process> - Intermediate and terminal channels:
ch_<previousprocess>_for_<nextprocess>
Parameters should be initialised and defined with default values within the params scope in nextflow.config.
They should also be documented in the pipeline JSON schema.
To update nextflow_schema.json, run:
nf-core pipelines schema buildThe schema builder interface that loads in your browser should automatically update the defaults in the parameter documentation.
If you write a local module, specify a default set of resource requirements for the process.
Sensible defaults for process resource requirements (CPUs, memory, time) should be defined in conf/base.config.
Specify these with generic withLabel: selectors, so they can be shared across multiple processes and steps of the pipeline.
nf-core provides a set of standard labels that you should follow where possible, as seen in the nf-core pipeline template. These labels define resource defaults for single-core processes, modules that require a GPU, and different levels of multi-core configurations with increasing memory requirements.
Values assigned within these labels can be dynamically passed to a tool using the the ${task.cpus} and ${task.memory} Nextflow variables in the script: block of a module (see an example in the modules repository).
If you use a new feature from core Nextflow, bump the minimum required Nextflow version in the pipeline with:
nf-core pipelines bump-version --nextflow . <min_nf_version>If you update images or graphics, follow the nf-core style guidelines.