Tower Configuration

Modified on Wed, 14 Sep 2022 at 08:47 AM

Q: Can a custom path be specified for the tower.yml configuration file?

Yes. Provide a POSIX-compliant path to the TOWER_CONFIG_FILE environment variable.

Q: Why do parts of tower.yml not seem to work when I run my Tower implementation?

There are two reasons why configurations specified in tower.yml are not honoured by your Tower instance. Either:

There is a typo in one of the key value pairs, or
There is a duplicate key present in your file.

# EXAMPLE
# This block will not end up being enforced because there is another `tower` key below.
tower:
  trustedEmails:
    - user@example.com

# This block will end up being enforced because it is defined last.
tower:
  auth:
    oidc:
      - "*@foo.com"

Q: Do you have guidance on how to create custom Nextflow containers?

Yes. See this.

Q: What DSL version does Nextflow Tower set as default for Nextflow head jobs?

As of Nextflow 22.03.0-edge, DSL2 is the default syntax.

To minimize disruption on existing pipelines, Nextflow Tower version 22.1.x and later are configured to default Nextflow head jobs to DSL 1 for a transition period (ending TBD).

You can force your Nextflow head job to use DSL2 syntax via any of the following techniques:

Adding export NXF_DEFAULT_DSL=2 in the Advanced Features > Pre-run script field of the Tower Launch UI.
Specifying nextflow.enable.dsl = 2 at the top of your Nextflow workflow file.
Providing the -dsl2 flag when invoking the Nextflow CLI (e.g. nextflow run ... -dsl2)

Q: Can Tower to use a Nextflow workflow stored in a local git repository?

Yes. As of v22.1, Nextflow Tower Enterprise can link to workflows stored in local git repositories. Do the following:

Volume mount your repository folder into the Tower Enterprise backend container.
Update your tower.yml with the following configuration:

tower:
  pipeline:
    allow-local-repos:
      - /path/to/repo

Note: This feature is not available to Tower Cloud users.

Q: Am I forced to define sensitive values in tower.env?

No. You can inject values directly into tower.yml or - in the case of a Kubernetes deployment - reference data from a secrets manager like Hashicorp Vault.

Please contact us for more details if this is of interest.