I am running the pipeline using nextflow's google cloud batch mode. I am not specifying a regions bed file, so it looks like the pipeline sets the bed file to a placeholder string NO_REG_BED:
This works when using an executor that does not need to do any staging, because checkIfExists is set to false and then the process filterHostReads checks to see whether it actually exists in the bash script:
Operating System
Ubuntu 22.04
Other Linux
No response
Workflow Version
v0.5.3-g8b9748b
Workflow Execution
Command line
EPI2ME Version
No response
CLI command run
Workflow Execution - CLI Execution Profile
custom
What happened?
I am running the pipeline using nextflow's google cloud batch mode. I am not specifying a regions bed file, so it looks like the pipeline sets the bed file to a placeholder string
NO_REG_BED
:https://github.com/epi2me-labs/wf-clone-validation/blob/8b9748bc00aac4f531778d7d6d2f9278f26e4201/main.nf#L691
This works when using an executor that does not need to do any staging, because
checkIfExists
is set to false and then the processfilterHostReads
checks to see whether it actually exists in the bash script:https://github.com/epi2me-labs/wf-clone-validation/blob/8b9748bc00aac4f531778d7d6d2f9278f26e4201/main.nf#L69
However, when using an executor like google cloud that does staging, nextflow tries to copy this nonexistent file and then gets confused (see log).
To get around this issue, I just ran
before the nextflow command. See this issue for discussion of various hacky ways to get around this that don't break cloud executors: https://github.com/nextflow-io/nextflow/issues/1694
Relevant log output
Application activity log entry
No response