It is likely because /juno/work/ci/resources/genomes/GRCh37/facets_snps/dbsnp_137.b37__RmDupsClean__plusPseudo50__DROP_SORT.vcf.gz is a string in db_files and doesn't get mapped properly in singularity; this is similar to an issue we ran into with java_temp.
Now the workaround is again binding those paths to singularity, but I would prefer we avoid that. That being said, we may need to take this opportunity to change all potentially problematic sections in the YAML-generation step to accommodate this needed change.
vep_data might need to be changed (maybe as a Directory?); vep_data, custom_enst, hotspot_list, hotspot_vcf, conpair_markers, and conpair_markers_bed are actually in their respective containers.
Ran into the following error:
See the CWL line here: https://github.com/mskcc/roslin-cwl/blob/master/workflows/project-workflow-sv.cwl#L23
It is likely because
/juno/work/ci/resources/genomes/GRCh37/facets_snps/dbsnp_137.b37__RmDupsClean__plusPseudo50__DROP_SORT.vcf.gz
is astring
indb_files
and doesn't get mapped properly insingularity
; this is similar to an issue we ran into withjava_temp
.Now the workaround is again binding those paths to singularity, but I would prefer we avoid that. That being said, we may need to take this opportunity to change all potentially problematic sections in the YAML-generation step to accommodate this needed change.
For example:
vep_data
might need to be changed (maybe as aDirectory
?);vep_data
,custom_enst
,hotspot_list
,hotspot_vcf
,conpair_markers
, andconpair_markers_bed
are actually in their respective containers.Just need to change!