wayneeseguin/rvm-test — Issue #7: Next Evolution of process transparency
Author: deryldoucette
Created: 2011-10-26 15:51:25+00:00
State: open

This is froma conversation I had with @mpapis in #beginrescueend on freenode about what I wanted. I was trying to speak out the conceptual idea i was playing with. This is the results:

```txt

11:01:05 deryl: can anyone recommend a gem to fulfill the need inherent in the idea of using ruby to launch, break apart, and monitor all aspects of the bash environment and scripts executed via %x[], ``, or exec (heck even direct System is fine) and to be able to generate and cull logging?
11:01:25 deryl: basically trying to extend the level of information captured from rvm-test testruns which contain ruby and bash commands to execute.
11:01:36 deryl: i'd like to be able to execute a single, batched, or Marshalled replay and be able to capture all (and eventually named) environmental variables, std*, library calls, OS system calls, and timing blocks for commands.
11:01:49 deryl: is there a gem that already contains the mechanics of the different aspects of that?
11:01:56 deryl: or is this a 'too wide, you'll have to write your own to include the mechanicals like accessing executed commands, spawned-environment vars, etc
11:01:58 deryl: "
11:06:03 mpapis: deryl: does any of the popen2-4 does that ?
11:07:33 deryl: mpapis, some
11:07:54 deryl: going to have to read deeper into IO i guess
11:08:55 mpapis: know your tools ;)
11:09:16 deryl: yeah yeah ;p
11:14:32 deryl: mpapis, basically I wanted to know if there was something already developed. I'm sure I'm not the first one to want to get to all aspects of the lifecycle of a file and its own spawned-environment. There are certain call structures that are the same regardless of the value of the cmdstring. there's also known debugging points and what txt they would generally generate.
11:15:01 deryl: i thought there might possibly be a gem already built with that information exposed
11:15:24 deryl: rather than having to write all of it on my own, though i certainly will do so if there isn't one.
11:15:53 deryl: this is me casting about
11:23:58 mpapis: there has to be something to work interactively with shell session ... if there is not i would be disappointed
11:25:35 deryl: i'm wondering if i'm thinking more performance monitoring than i actually am debugging
11:26:14 deryl: i mean i want to pull as much output as possible with control on the level of that flow, but i'm really just examining that return. i'm not modifying it
11:26:53 deryl: it'll be used elsewhere in the program but all i'm really trying to pull out is all the details associated with the full lifecycle of a single process.
11:27:13 deryl: anything that could be used for decision making.
11:28:22 deryl: if i have the full output of the environment of whatever is being executed (such as set +x information for the bash shell the command is exec'd in, and --trace information from rvm itself)
11:29:11 deryl: then we can key in on things like sm console does where you can set traps for environment variables. if I report that trap back up to the suite itself, I can monitor changes
11:30:09 deryl: i can make decisions in that process and back higher at the report level to do things like modify the running process, or perhaps generate an additional gist of that portion of the command's environment
11:30:14 mpapis: interesting
11:31:05 deryl: basically, i want to peer in deeper at each aspect of each command that run.rb has thrown at it
11:31:21 deryl: pull that data
11:31:27 deryl: make decision trees out of it
11:32:42 mpapis: i would move debugging for later, first - one session - second tests, they give more value and should be easier to implement
11:33:35 deryl: will also aid in expanding TestSet (which I'm about to add Model wise) encapsulation. We see that this TestSet contains the commands to install rbx, and create a gemset. We have X number of TestReports associated with this test set that makes use of the same commands. Lets pull prior records where these commands were the same and see what the rvm_path was set to at what stage in the process.
11:34:29 deryl: For those specific portions of the command set thats used to start and complete the rbx installation portion.
11:35:31 mpapis: ah so you move output of command to the connection between command and test case ?
11:35:44 deryl: by storing the environment of each command you can create an Environment model which has_many :commands and if you link certain command sequences to the Environment, then those particular command's previous environments become available
11:36:22 deryl: and you can rerun commands for a specific environment simply by including the Environment object in your TestSet. Multiple Environments of course being allowed.
11:36:37 deryl: mpapis, exactly
```

So in the end, we'd end up with something like this:

TestSet = (x.times TestCase[ x.times TestReport[:commands] + x.times Environment[:testreports] ]) where TestReport[:commands] is the TestCase's test_report for the commands to be run under that TestCase, coupled with the known Environments that contain prior TestReports where their commands matched the ones you're running.

Commands to manage all of this are in TestSet, which in turn could be controlled by becoming members of a TestBank.