The cwl_utils parser for some reason assigns slightly different step input ID values depending on whether the step is parsed from a separate CommandLineTool CWL file or directly from the run field in the Workflow CWL file steps section
e.g. separate file: file://foo/bar#iterations; inline run field: file://foo/bar#lulesh/iterations
This caused a key lookup in the input-to-source map to fail, raising an exception
Fixed by stripping the extraneous prefix (e.g. lulesh/) from the step input ID
Fixed a related issue where the TASKS_NOJOB_GOLD tasks in test_parser.py had empty inputs lists, causing test_parse_workflow_no_job() to fail erroneously after the bug was fixed (it was passing before the fix)
The gold standard tasks had empty inputs lists because that's what the parser was returning, which is possibly another bug
It may need to be further investigated why the parser was returning tasks with empty inputs lists when parsing the cf.cwl test file rather than raising an exception like the lulesh-mpi workflow
cwl_utils
parser for some reason assigns slightly different step input ID values depending on whether the step is parsed from a separate CommandLineTool CWL file or directly from therun
field in the Workflow CWL filesteps
sectionfile://foo/bar#iterations
; inline run field:file://foo/bar#lulesh/iterations
lulesh/
) from the step input IDTASKS_NOJOB_GOLD
tasks intest_parser.py
had emptyinputs
lists, causingtest_parse_workflow_no_job()
to fail erroneously after the bug was fixed (it was passing before the fix)inputs
lists because that's what the parser was returning, which is possibly another buginputs
lists when parsing thecf.cwl
test file rather than raising an exception like the lulesh-mpi workflowThis PR resolves #643