Add optional correction attribute to tests giving command to run on test failure

[sshipway]

Describe the feature:
Goss tests should have an optional 'correction' attribute, containing a generic OS command to run in the case of test failure. This would allow goss to also self-heal minor faults.

This may be considered out of scope of the intent of goss, since it is making changes (fixes) rather than simply reporting; however I consider it a very useful feature to add.

Describe the solution you'd like
Add a new attribute to goss test, 'correction', containing an OS command.
In the event of the goss test failing, if a 'correction' command is defined, the 'correction' command is run, and then the goss test then re-tried. If the new ettempt passes then the test is considered a pass (though it should log that recovery was required)

Describe alternatives you've considered
A separate script couldrun correction commands after a goss run fails. However this is much harder to target as it requires rerunning all the tests, even the successful ones, plus identifying which test failed - and therefore which correction to attempt, if one is available - is more difficult from outside the goss framework

[aelsabbahy]

Reflecting on this a bit, it sounds like it's starting to get into the territory of configuration management (chef, puppet, ansible, etc.). Guess my question is.. what is the value of this over an idempotent configuration management tool?

My initial reaction is that, while this seems like a very cool feature. it may be a bit out of scope and could lead to some trying to use goss as a bad CM tool.

[sshipway]

I do understand your view here, and agree that it is probably going outside the scope of goss being a pure test/validation tool. I suppose the only in-scope reason for this would be to allow an on-failure command to collect more information, such as to run additional root-cause tests, but that is probably not enough justification.

[aelsabbahy]

Out of curiosity do you have a concrete example of a use case for root cause?

Mostly asking since I recently added the ability to have debug output which currently shows the Stdout/stderr of a command and looking for possible improvements to other tests logging.

I'm wondering if there's possibly a way to achieve the desired results of your last suggestion through enhanced logging