- Difficulty level: easy
- Time need to lean: 10 minutes or less
- Key points:
- Option
-n
turns workflow into dryrun mode sos dryrun
is equivalent tosos run -n
- Option
The dryrun
mode is used to check for errors of SoS workflows and running environments without actually executing any of the actions and tasks. It can be specified with option -n
to command run
(sos run -n
, sos-runner -n
, or %run -n
) or with subcommand dryrun
(sos dryrun
).
The first use of dryrun mode is to check syntax error of scripts. For example, the following script yields an error because the header of the step is wrong (should use :
instead of ,
).
Script-executing actions such as run
, sh
, and python
does not execute the scripts in dryrun mode. In stead, they will print the script with the command to execute them. This usage allows you to check if the scripts are interpolated correctly, or even executing them outside of SoS.
For example, the following script will print the expanded version of the scripts to be executed:
It is worth noting, however, that sos executes Python statements in dryrun mode as usual so your workflow will appear to be executed normally if you do not use actions.
For example, if you implement your steps in Python and include them directly, the step will be executed
and the output files will be generated:
Another consequence of running workflows in dryrun mode is that SoS generates empty placeholder files during dryrun and remove them afterwards. This allows the workflows to be executed "normally" because the execution of the next steps might depend on the existence of the output files.
For example, when running in dryrun mode, the following script will be executed "normally". The _input
files (which are the output of step 10) could be opened at step 20, but the content would be empty:
test_1.txt
and test_2.txt
would be generated normally in run mode:
External tasks are executed in dryrun
mode as follows:
- Only task from the first substep will be generated and submitted.
- The task will be submitted to remote hosts as usual, with input files synchronized to remote host if needed. This allows you to test if the remote hosts are accessible.
- The task will be executed in
dryrun
mode, and will print instead of execute the scripts defined in actions.
When an action is executed in docker in dryrun mode, SoS would download the docker image if needed but will not execute the script. Instead, SoS will print the interpolated script and the docker command needs to execute the script.
For example, running an docker_build
action in dryrun mode yields the following output:
and running a script in docker in dryrun mode: