qDup provides the ability to define utility scripts in external .yaml files and pass those files as CLI arguments when starting thq qDup process, e.g. java -jar /path/to/qDup.jar ./myWorkflow.yaml ./utils/myUtilScripts.yaml
It is likely that many qDup scripts will fail if users attempted to execute the scripts,without passing the additional script paths on the command line. Therefore, the utility scripts form an integral part of the runtime environment. However, the dependency is not expressed in the script .yaml, but passed as parameters via the command line. In order to unify the script definition (including dependencies) it would make sense to include the the dependency information the actual script definition itself, something such as
import:
- ./util/doSomething.yaml
- https://raw.githubusercontent.com/Hyperfoil/qDup/master/docs/examples/helloWorld.yaml
scripts:
- do-something:
- sh: cd /tmp/something
- script: do
with:
test: test2
qDup provides the ability to define utility scripts in external .yaml files and pass those files as CLI arguments when starting thq qDup process, e.g.
java -jar /path/to/qDup.jar ./myWorkflow.yaml ./utils/myUtilScripts.yaml
It is likely that many qDup scripts will fail if users attempted to execute the scripts,without passing the additional script paths on the command line. Therefore, the utility scripts form an integral part of the runtime environment. However, the dependency is not expressed in the script .yaml, but passed as parameters via the command line. In order to unify the script definition (including dependencies) it would make sense to include the the dependency information the actual script definition itself, something such as