-
-
Notifications
You must be signed in to change notification settings - Fork 359
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Idea: track command, args, cwd, env of each process #158
Comments
You could organize/combine hierarchically as well (what are all the pid's that pid X launched) |
addaleax
added a commit
to addaleax/nyc
that referenced
this issue
Aug 24, 2016
Add a `--show-process-tree` that shows a pretty tree of all spawned processes after `nyc` has run. The data files for that are stored in `processinfo` are stored in `(temp directory)/processinfo` so that they don’t interfere with the fixed format of the coverage files. Fixes: istanbuljs#158
addaleax
added a commit
to addaleax/nyc
that referenced
this issue
Aug 27, 2016
Add a `--show-process-tree` that shows a pretty tree of all spawned processes after `nyc` has run. The data files for that are stored in `processinfo` are stored in `(temp directory)/processinfo` so that they don’t interfere with the fixed format of the coverage files. Fixes: istanbuljs#158
bcoe
pushed a commit
that referenced
this issue
Sep 2, 2016
* feat: gather process tree information Add a `--show-process-tree` that shows a pretty tree of all spawned processes after `nyc` has run. The data files for that are stored in `processinfo` are stored in `(temp directory)/processinfo` so that they don’t interfere with the fixed format of the coverage files. Fixes: #158 * [squash] cleanup: make ProcessTree instances nodes of the tree themselves This is in preparation for per-subtree coverage at some point. * [squash] add short section about --show-process-tree to readme
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Nyc right now creates a really interesting record of not just what lines and files were covered, but also what lines and files were covered by each individual process, organized by pid.
I was thinking it might be interesting to have a way to drill into the details of each of those commands.
It might be worth putting off until someone has an idea for how to report on this, but even just for forensics or saving coverage reports for later analysis, it could be interesting. And it's probably relatively trivial to just dump some process info into the json along with the coverage data. If it's problematic to put it in the same file, it could be dropped into a file at
.nyc_coverage/processinfo/<pid>.json
containing:The text was updated successfully, but these errors were encountered: