Please describe what you would like to see in this project
When defining deployer configuration details in a workflow, this currently overwrites the default deployer. This is problematic when you simply need to add additional features to a step's deployment, such as privilege or a bind mount.
Please describe your use case
A single step in a workflow needs to run with host networking and with a bind mount. The default config in this case uses podman remote. Because the workflow deployer config completely overwrites the deployer for that step, if the podman remote parameters are not also supplied in the workflow deployer config, the result is that the step deploys locally instead of via podman remote, breaking the intended behavior of the workflow.
Defining the podman remote setting statically in the workflow on the other hand will break the use case of the workflow being intentionally run locally.
Please describe what you would like to see in this project
When defining deployer configuration details in a workflow, this currently overwrites the default deployer. This is problematic when you simply need to add additional features to a step's deployment, such as privilege or a bind mount.
Please describe your use case
A single step in a workflow needs to run with host networking and with a bind mount. The default config in this case uses podman remote. Because the workflow deployer config completely overwrites the deployer for that step, if the podman remote parameters are not also supplied in the workflow deployer config, the result is that the step deploys locally instead of via podman remote, breaking the intended behavior of the workflow.
Defining the podman remote setting statically in the workflow on the other hand will break the use case of the workflow being intentionally run locally.