Replies: 2 comments 3 replies
-
|
That's a good point. My first thought is that we should improve the Tower task detail including the list of input and output files or add the ability to browse the task work dir. |
Beta Was this translation helpful? Give feedback.
-
|
There's definitely a lot of utility in building out features in Tower, but another need to consider is the ability to rapidly parse input/output files with command line utilities. For example, if an error is caused by a file not being gzip-compressed appropriately, that is very easy to diagnose on the command line (for an expert-level user), but much less easy in the browser. It might be worth considering whether there is a command-line utility that could streamline this type of debugging. |
Beta Was this translation helpful? Give feedback.
-
|
Basically do you need to list the tasks input files? |
Beta Was this translation helpful? Give feedback.
-
|
The items I'm thinking about are:
|
Beta Was this translation helpful? Give feedback.
-
|
Thinking more, I think making a Bash wrapper that launches a FUSE driver e.g. Gooyfs and jump into the bucket work dir could do be a nice workaround |
Beta Was this translation helpful? Give feedback.
-
When running Nextflow locally, it's really easy to debug a failure at a particular step. You can just:
cdto the work directoryls -lah)Doing the same thing for workflows run remotely (e.g., on AWS) is a lot harder. I'm finding myself doing a lot of:
aws s3 cp $WORK_DIR/.command.log - | lessto look at the logs a stepaws s3 cp $WORK_DIR/.command.run - | grep s3 | grep downloadto find the inputs to that stepI don't know what the best implementation is, but some way to make it easier to perform these debugging activities would be really useful.
cc: @pditommaso
Beta Was this translation helpful? Give feedback.
All reactions