From ed01d91eece5183ae52fca69fa7b16b85c24210c Mon Sep 17 00:00:00 2001 From: Marc Hoeppner Date: Thu, 15 Feb 2024 07:25:02 +0100 Subject: [PATCH] Updating linting action --- .github/workflows/linting.yml | 2 +- docs/developer.md | 9 +++++---- docs/installation.md | 6 +++--- 3 files changed, 9 insertions(+), 8 deletions(-) diff --git a/.github/workflows/linting.yml b/.github/workflows/linting.yml index ecfb32a..9ed9269 100644 --- a/.github/workflows/linting.yml +++ b/.github/workflows/linting.yml @@ -23,5 +23,5 @@ jobs: run: npm install -g npm-groovy-lint - name: Run groovy lint check - run: npm-groovy-lint -l error ${GITHUB_WORKSPACE} + run: npm-groovy-lint ${GITHUB_WORKSPACE} diff --git a/docs/developer.md b/docs/developer.md index 228c181..ccbca83 100644 --- a/docs/developer.md +++ b/docs/developer.md @@ -18,8 +18,8 @@ This template specifically is set up to work with the following VS extensions: This pipeline base is organized in the following way: -* `main.nf` - entry point into the pipeline, imports the core workflow from workflow/.nf -* `workflow/` - the actual core logic of the pipeline; imports sub-workflows from subworkflow/.nf +* `main.nf` - entry point into the pipeline, imports the core workflow from `workflow/.nf` +* `workflow/` - the actual core logic of the pipeline; imports sub-workflows from `subworkflow/.nf` * `subworkflow/.nf` - a self-contained processing chain that is part of the larger workflow (e.g. read alignment and dedup in a WGS calling workflow) * `modules/.nf` - A command line tool/call that can be imported into a (sub)workflow. @@ -106,7 +106,7 @@ Here, standard refers to the default site configuration ('standard') - change it ## Linting -Nextflow does not have a dedicated linting tool. However, since most of nextflow is actually Groovy, the groovy linting suite works just fine, I find. I would strongly recommend setting this up in a [conda] environment, but it should also work on your *nix system directly (albeit with some minor pitfalls re: java version) +Nextflow does not have a dedicated linting tool. However, since most of nextflow is actually Groovy, the groovy linting suite works just fine, I find. I would strongly recommend setting this up in a [conda](https://github.com/conda-forge/miniforge) environment, but it should also work on your *nix system directly (albeit with some minor pitfalls re: java version) ``` conda create -n nf-lint nodejs openjdk=17.0.10 @@ -120,7 +120,8 @@ In your pipeline directory, you can check all the files in one go as follows: npm-groovy-lint ``` -You'll note that some obvious errors/warnings are omitted. This behavior is controlled by the settings in .groovylintrc [documentation](https://www.npmjs.com/package/npm-groovy-lint), included with this template. If you need to switch on some stuff, just add it the config file, and vice-versa. +You'll note that some obvious errors/warnings are omitted. This behavior is controlled by the settings in .groovylintrc [documentation](https://www.npmjs.com/package/npm-groovy-lint), included with this template. If you need to switch on some stuff, just add it the config file - and vice-versa. + ## Sending report emails diff --git a/docs/installation.md b/docs/installation.md index 648917f..b35c0f9 100644 --- a/docs/installation.md +++ b/docs/installation.md @@ -5,9 +5,9 @@ This pipeline requires a site-specific configuration file to be able to talk to your local cluster or compute infrastructure. Nextflow supports a wide range of such infrastructures, including Slurm, LSF and SGE - but also Kubernetes and AWS. For more information, see [here](https://www.nextflow.io/docs/latest/executor.html). -Please see conf/medcluster.config for an example of how to configure this pipeline for a Slurm queue. +Please see conf/lsh.config for an example of how to configure this pipeline for a Slurm queue. -All software is provided through Docker containers - this requires for your compute system to run either Docker or Singularity (more common on HPC systems). Details on how to specify singularity as your container engine are provided in the config file for our medcluster (medcluster.config). +All software is provided through Docker containers - this requires for your compute system to run either Docker or Singularity (more common on HPC systems). Details on how to specify singularity as your container engine are provided in the config file for our lsh system (lsh.config). With this information in place, you will next have to create an new site-specific profile for your local environment in `nextflow.config` using the following format: @@ -30,5 +30,5 @@ This would add a new profile, called `your_profile` which uses (and expects) con `resources.config` Gives information about the files that are to be used during analysis for the individual human genome assemblies. -`your_cluster.config` Specifies which sort of resource manager to use and where to find the GATK resource bundle on your cluster file system (see below). +`your_cluster.config` Specifies which sort of resource manager to use and where to find e.g. local resources cluster file system (see below).