When mkconcore.py hits an error it calls quit(), which exits with status 0. concore build only looks at the return code of the mkconcore subprocess, so any of these errors end up being reported as a successful build.
To reproduce, take the project from concore init demo, rename src/script.py to src/script.rb and change the node label to N1:script.rb, then run:
concore build demo/workflow.graphml --source demo/src --output out --type posix
echo $?
The command prints ✓ Workflow generated and ✓ Workflow ready!, writes out/STUDY.json, and exits with 0. The real error from mkconcore (Extension .rb is unsupported) never shows up because build only prints mkconcore's stderr when the subprocess fails.
Same thing happens for duplicate node labels, an invalid type argument, a missing concore runtime file, and a C++ node with --type docker. There are 14 of these quit() calls on error paths in mkconcore.py.
Expected: mkconcore exits non-zero on these errors, and concore build prints the error and exits with 1.
What it looks like on dev:
When mkconcore.py hits an error it calls
quit(), which exits with status 0.concore buildonly looks at the return code of the mkconcore subprocess, so any of these errors end up being reported as a successful build.To reproduce, take the project from
concore init demo, renamesrc/script.pytosrc/script.rband change the node label toN1:script.rb, then run:The command prints
✓ Workflow generatedand✓ Workflow ready!, writesout/STUDY.json, and exits with 0. The real error from mkconcore (Extension .rb is unsupported) never shows up because build only prints mkconcore's stderr when the subprocess fails.Same thing happens for duplicate node labels, an invalid type argument, a missing concore runtime file, and a C++ node with
--type docker. There are 14 of thesequit()calls on error paths in mkconcore.py.Expected: mkconcore exits non-zero on these errors, and
concore buildprints the error and exits with 1.What it looks like on dev: