playbook_variables (3.1) define variables in playbook scope. step_variables (4.1) define variables in step scope. These are the only two explicit variables scope in a playbook: global, or step-specific.
All playbook steps can define step_variables specific to that step, and which can be accessed by objects “used or referenced by that object” (10.18.1).
in_args are used in playbook action steps, or action steps. They are a list of string, i.e., the keys of the variables to resolve, and refer to variables used within that step or playbook.
out_args are also used in playbook action steps, or action steps. They are also a list of strings, i.e., the keys of the variables that are expectedly modified by the execution of the step.
Note that:
A workflow execution tool will always resolve/substitute variables in a step upon parsing the field that contains variables, hence, in_args potentially does not serve a purpose.
The resolution/substitution of a variable can still be expected to first check the local step scope (step_variables), then the global playbook scope (playbook_variables)
But as discussed, its use is intended to allow an efficient "fetch" of the relevant variables for the context, in the use-case of very large playbooks. This may be made clearer.
In the general case, there is little meaning that out_args refer to step-local variables, as once the step is executed, the step-local variables will be out of scope of the playbook.
step-local out_args makes sense only in specific cases such as:
where an action step uses multiple commands, and subsequent commands use variables obtained from previous commands.
where a variable returned in a step should be "pushed out" of the workflow execution, for any use that cannot be addressed via a workflow step
In the general case, it makes sense if out_args refer to playbook scope variables, as updating them will contribute information to the workflow.
IF and WHILE condition branches may only need step_variables if their condition is not dependent on the workflow. If the condition is dependent on the workflow, then the variables used in the condition need to be global, as the condition changes based on the execution of previous steps, or consequent branch steps. (Alternatively, an additional playbook branch variables scope may be added).
Possible ways to address
Introduce explicit branch scope for variables for if, while, and parallel steps
Document best-practices related to the envisioned use of in_args, and step-local out_args
Concern
Observing that:
Note that:
Possible ways to address