Is your feature request related to a problem? Please describe.
I'm always frustrated that I have to repeat sudo -p <myuser> -c over and over again in the run section.
Describe the solution you'd like
The cleanest solution that would keep backward compatibility would involve introducing a map as a list item underneath run that allows for switching users:
run:
- as: root
cmds:
- microdnf install -y tar gzip
- python3 -m pip install -U pip && pip3 install ansible
- as: builduser
cmds:
- ansible .....
Users could still use a simple list of commands under the run section as always.
This syntax could allow for additional options in the future for each section of commands, like use_sudo: true to use sudo instead of su, or even things like chain_cmds_with: and to specify a section you want to be a single layer. That last future feature has a number of ways it could be implemented.
Personally, I think this new structure greatly improves readability of the YAML code and nicely allows for future syntactic sugar.
This does increase implementation complexity. For example, you may be assuming a colon in any item in the list of commands in run will always be for a command, but now you would need to pre-check for those new keywords.
Describe alternatives you've considered
Option 0
I initially considered a top-level build_user option, but that would be a lot less flexible since you could only use it once and then switching users would be difficult or impossible.
Just to list other possibilities with this syntax I considered....
Option 1 - The stateful route
This one lowers the layering of the syntax but is a bit less true to the 'spirit' of YAML:
run:
- switch_user_to: root
- microdnf install -y tar gzip
- as_layer: # This could be anything, even '&&:' or '||:' or even nothing (if you also assume a list in a list is a single layer)
- python3 -m pip install -U pip
- pip3 install ansible
- switch_user_to: builduser
- ansible ...
Additional context
You could choose to just make this syntax style its own alternative section to run: and make it more layer-focused. Maybe something like
layer_defaults:
run_as: root
use_sudo: true
layers:
- microdnf install -y tar gzip # This is the first layer
- cmds: # This is a second, single layer and commands are and'ed by default - 'cmds:' could be omitted but is there for readability
- python3 -m pip install -U pip
- pip3 install ansible
- run_as: builduser
cmds:
- ansible ...
This context is only food for thought for alternatives. I personally like my proposal above with Option 1 being my second choice.
Is your feature request related to a problem? Please describe.
I'm always frustrated that I have to repeat
sudo -p <myuser> -cover and over again in therunsection.Describe the solution you'd like
The cleanest solution that would keep backward compatibility would involve introducing a map as a list item underneath
runthat allows for switching users:Users could still use a simple list of commands under the
runsection as always.This syntax could allow for additional options in the future for each section of commands, like
use_sudo: trueto use sudo instead of su, or even things likechain_cmds_with: andto specify a section you want to be a single layer. That last future feature has a number of ways it could be implemented.Personally, I think this new structure greatly improves readability of the YAML code and nicely allows for future syntactic sugar.
This does increase implementation complexity. For example, you may be assuming a colon in any item in the list of commands in
runwill always be for a command, but now you would need to pre-check for those new keywords.Describe alternatives you've considered
Option 0
I initially considered a top-level
build_useroption, but that would be a lot less flexible since you could only use it once and then switching users would be difficult or impossible.Just to list other possibilities with this syntax I considered....
Option 1 - The stateful route
This one lowers the layering of the syntax but is a bit less true to the 'spirit' of YAML:
Additional context
You could choose to just make this syntax style its own alternative section to
run:and make it more layer-focused. Maybe something likeThis context is only food for thought for alternatives. I personally like my proposal above with Option 1 being my second choice.