Add tests for all linux pack actions

[blag]

The contrib linux pack has a few broken actions (check_loadavg, check_processes, dig: #4993, diag_loadavg, netstat: #4947, possibly more) at least on CentOS 8. It's really disheartening to spin up StackStorm and immediately run into broken actions.

We should add tests for those actions to the pack.

The tests from the core pack can be used as a template for writing tests for the linux pack.

I will try to add tests for the dig action in my PR #4993, to serve as a concrete example, but adding tests would be a useful way to introduce somebody to developing StackStorm that would have an immediate impact.

[winem]

As already mentioned via Slack, I'll take care of it and start working on it now. Am still testing the actions to see which one exactly fail on Centos8 and will start to work on the MR soon.

[winem]

Summary of failing actions:

• linux.lsof - a default Centos8 setup does not have lsof installed
• linux.diag_loadavg - issue with the workflow which uses on-failure: email_escalation while email_escalation is not defined
• linux.loadavg, linux.check_processes fail because python is not available on a default Centos8 setup (only python2 and python3)
• linux.service has the same python issue + No module named st2common.util.shell where I assume that the script is copied to the destination host and the module import fails because the script is no longer executed in the scope of the virtual environment. This was also reported in #5004

All other actions work fine.

[blag]

Copying and pasting this from Slack:

For the netstat action there really isn’t much to do since it’s a straight remote-shell-cmd action, and it only has a single user-specified parameter, args. So this one probably doesn’t need a unit test.

Same story for the cp, mv, netstat_grep, pkill, rm, rsync, scp, and vmstat actions.

I’m a little confused why the file_touch action doesn’t use the touch command…that could probably be changed, but if you do I would rename the existing file_touch action to something like file_init.

For the service action, it’s a remote-shell-script but it’s actually a Python script, so you can probably import directly from it, mock up and monkeypatch the sys and subprocess modules in it, and then assert that the right command arguments are passed to subprocess.call.

check_loadavg needs some tests, I would mock up and monkeypatch loadAvgFile and cpuInfoFile, override sys.stdout and check its output. Once you’ve got some tests, it then needs to be updated to support both Python 2 and 3 (except Exception:).

check_processes needs tests - you don’t need to test every method, but I would test at least byState, byPid, and byName. First, choose a pid number and set the action instance's myPid property to it, then create a test fixture directory that contains directories with purely numeric names, a few with non-numeric names, and a name that matches your chosen myPid number (say: 3456. Make sure you put stat and cmdline files in each pid directory:

proc_fixture/
proc_fixture/1234/
proc_fixture/1234/stat
proc_fixture/1234/cmdline
proc_fixture/2345/
proc_fixture/2345/stat
proc_fixture/2345/cmdline
proc_fixture/3456/
proc_fixture/3456/stat
proc_fixture/3456/cmdline
proc_fixture/abcd/
proc_fixture/abcd/stat
proc_fixture/abcd/cmdline
proc_fixture/4567/
proc_fixture/4567/stat
proc_fixture/4567/cmdline

Set the procDir property to your fixture directory, override sys.stdout and check that against a known value.

For wait_for_ssh, we need to check two of the three use cases: (1) unconnectable host (SSH timeout), and (2) instantly connectable host (eg: localhost). Use test_action_dig.py as a template for this.

If you need help standing up a test environment to begin with, I would dig through the Travis config and rerun the same commands in a VM.