-
-
Notifications
You must be signed in to change notification settings - Fork 231
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NetworkAccess requirement not applicable in cwltool:overrides #1754
Comments
Hello @alexiswl What is the |
Version of the workflow is v1.1 Pipeline is here: https://github.com/umccr/cwl-ica/tree/bclconvert-4.0.3/workflows/bclconvert-with-qc-pipeline/4.0.3 (it's on a branch though so will zip up a copy for you). I've added Network Access to the tool directly now but should only be necessary when the container is a dragen fpga container |
I can replicate this with a simple tabix workflow if that is going to be easier |
|
Apologies, have updated the input json above to be a valid json |
Hi Michael, Yes the error goes away but --net isn't updated. It seems I'm having a little issue setting the overrides on this one. We've been using cwltool version 3.0.20201203173111 in production but I got the same warning results above using the most recent stable version (which is why I put 3.1.20221018083734 above). When setting the overrides I specify the path to the subworkflow (relative to the main workflow) that invoked the tool I'd like to override, followed by a #, followed by the step id of that tool. This is consistent with the name used for the step inside cwltool --debug logs, the step is referenced as This works in 3.0.20201203173111 (I've tried with a standard DockerRequirement override) but not in the most stable version (downloaded from pip cwltool 3.1.20221018083734) nor when installed from source with the overrides-v1_1+ branch. Update I needed to preface the step with the id of the workflow THEN place in the name of the step So the overrides key |
@mr-c have retested this with the overrides v1_1+ branch with the updated overrides and can confirm this does work. Happy to close |
I would like to point out however, there appears to be a discrepancy between cwltool version 3.0.20201203173111 and cwltool version 3.1.20221018083734 as the ID required for a cwltool overrides. In this case |
Thanks for the update. Yes, there was a fix to how various items in the workflow DAG are identified. Are there examples in the readme or other docs that need updating? |
Thanks @mr-c
I think the documentation here does make sense for users who already understand the pattern, however it isn't easy to take the example used and apply it to a workflow with greater complexity, such as one with subworkflows. The documentation reflects the DAG identification for the latest CWLtool version, for the 2020 version currently used in our production systems I've noted this discrepancy in our docs. Personally, I used the CWL debug logs to help navigate how step IDs are set for use in overrides. |
I think a |
Expected Behavior
Allow user to specify network access in cwltool:overrides OR explictly error out saying this is not an acceptable override.
Actual Behavior
Tell us what happens instead
We get a warning at the top of the script
Input Json
Full Traceback
Your Environment
Check using
cwltool --version
The text was updated successfully, but these errors were encountered: