Show correct changed output in check mode #14
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Show correct changed output in check mode
Right now the command module has silly behavior in check mode. If the command is skipped because of a when block or something it shows as skipped. But if the command would actually run it ALSO shows as skipped despite the fact that the module knows that the command would run.
I'm not the only one annoyed by this either. This fixes:
Don't tell me that command doesn't support check mode when
supports_check_mode=True
.In addition there is another feature added that I simplifies annoying logic when trying to use check mode to run binaries that are created by the playbook itself -- mocks!
If you run this in check mode it will fail because
Run some command
is skipped and so the variable will never be defined. And if you addcheck_mode: false
to that task to fix it it will also fail because theaws
command isn't found. So you actually need to have a separate task to check if theaws
command exists and use that to skip both tasks but then you lose the information that in reality both of these tasks would be changed which defeats the entire point of check mode.With these patches we can do
And everything will "just work." In the case of an information gathering command you can do one better but it requires that you check for the command existence.
Which will use the mock if the
aws
command doesn't exist but actually run it if it does.