RunCommand resource

[SteveL-MSFT]

Summary of the new feature / enhancement

There are cases where a user already has scripts they've written and they want to incorporate it into their config as they start to transition to declarative. We don't want to promote usage of this, but also not have barriers to prevent adoption. This resource would implement get, set, and test which simply executes the defined command-line.

Proposed technical implementation details (optional)

The RunCommand resource takes a single command-line (split between executable and arguments array) to execute and returns the exit code and writes a WARNING message containing any STDERR output and an INFO message containing any STDOUT output. An ERROR is returned if the exit code is non-zero. This means that any non-standard command that emits a successful non-zero exit code needs to be wrapped in a script.

This resource would not be part of the base DSC v3 package and needs to be installed separately. May be worth considering emitting a WARNING message that this resource is not idempotent.

[denelon]

From the WinGet Configuration point of view, this is an "escape hatch" when no other DSC Resource is suitable. This wouldn't be idempotent unless the author went out of their way to make it idempotent. Given that level of effort it might be more valuable to build an idempotent DSC Resource.

WinGet as an orchestrator would also likely want to have some form of warning to the user about this concern of non-idempotence.

We would want copious documentation to warn users from going down this route. It's primarily intended to support organizations with existing investments in automation so they can leverage WinGet as an orchestrator so they don't have to completely re-write everything to leverage those existing invesments.

Our guidance would be to use this only as a temporary stop gap until a proper DSC solution is provided.

[SteveL-MSFT]

Possible example usage:

executable: powershell.exe
arguments:
- -noprofile
- -file
- foo.ps1
exitCode: 0

This would run: powershell.exe -noprofile -file foo.ps1 . We could allow passing in an exitCode in case success is non-zero and if not specified fails if non-zero.

[SteveL-MSFT]

@tgauth you want to try to implement this? You can use the process handling code in DSC as an example.

[SteveL-MSFT]

Thinking about this further, I think this resource implements only get and set. For get, it simply returns the output as described above, but does NOT run the command. set actually runs the command and the exitCode represents the actual axit code. This should effectively make it a no-op for get and test, while providing details in the output what would have been run. Docs will make this behavior clear.

If there is a scenario later that would want execution for get, we can revisit. Perhaps even call this resource RunCommandOnSet to make it more clear when reading a config.

cc @tgauth to make sure you see this change

[SteveL-MSFT]

WG agrees with current proposal pending real world feedback