I came across this while running sprocket lint on the broadinstitute/warp codebase. Several tasks there declare cpu as a String (e.g., cpu: "1"), and sprocket lint flags these as errors. I put up a fix in broadinstitute/warp#1811, but in doing so I realized the lint diagnostic isn't quite right for WDL 1.0 documents.
The WDL 1.0 spec does not formally define the cpu key. In 1.0, runtime keys are essentially arbitrary:
The runtime section defines key/value pairs for runtime information needed for this task. Individual backends will define which keys they will inspect so a key/value pair may or may not actually be honored depending on how the task is run.
(WDL 1.0 spec, Runtime Section)
Only docker and memory are given "recommended conventions" in 1.0. The formal type definitions for cpu, gpu, disks, maxRetries, and returnCodes were introduced in WDL 1.1.
Flagging a String-typed cpu value as an error in a version 1.0 document is technically incorrect, since the spec imposes no type constraint there. The type checking for these keys should only apply to documents declaring version 1.1 or later.
I came across this while running
sprocket linton the broadinstitute/warp codebase. Several tasks there declarecpuas aString(e.g.,cpu: "1"), andsprocket lintflags these as errors. I put up a fix in broadinstitute/warp#1811, but in doing so I realized the lint diagnostic isn't quite right for WDL 1.0 documents.The WDL 1.0 spec does not formally define the
cpukey. In 1.0, runtime keys are essentially arbitrary:Only
dockerandmemoryare given "recommended conventions" in 1.0. The formal type definitions forcpu,gpu,disks,maxRetries, andreturnCodeswere introduced in WDL 1.1.Flagging a
String-typedcpuvalue as an error in aversion 1.0document is technically incorrect, since the spec imposes no type constraint there. The type checking for these keys should only apply to documents declaringversion 1.1or later.