Skip to content
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

GitProcess: add NUnit TestCase FullName to trace2 output #409

Merged
merged 1 commit into from
Jul 21, 2020
Merged

GitProcess: add NUnit TestCase FullName to trace2 output #409

merged 1 commit into from
Jul 21, 2020

Conversation

jeffhostetler
Copy link
Contributor

@jeffhostetler jeffhostetler commented Jul 20, 2020

Use the GIT_TRACE2_ENV_VAR feature to insert the full name of the
NUnit TestCase into the Trace2 output stream.

This only covers Git invocations that use the Functional Test
harness (and not the ones using the Common/GitAPI mechanism).

This now also includes a sequence number to match up control and enlistment command pairs.

@jeffhostetler
Copy link
Contributor Author

This will cause a "def_param" event with the TestCase.FullName for each Git command. This will let us correlate the SID with the actual test. I'll push a later change to break out each Git command into a separate Trace2 file and then we can more easily grep
the logs.

@jeffhostetler
Copy link
Contributor Author

TODO Add a note to the code that fsmonitor-daemon processes that are implicitly started by fsmonitor-query-daemon() will inherit the SID of the client command -- which is correct -- but may be misleading when using the long-running or enlistment-per-fixture mode. (I'm assuming that in these modes, the daemon will be started by the first unit test that needs it after the enlistment is created -- rather than having a daemon started per test case.)

Use the GIT_TRACE2_ENV_VAR feature to insert the full name of the
NUnit TestCase into the Trace2 output stream using the XXX_TEST_FULLNAME
environment variable.

This only covers Git invocations that use the Functional Test harness
(and not the ones using the Common/GitAPI mechanism).

Also insert a "command sequence id" to match up control and enlistment
command pairs using the XXX_SEQUENCE_ID environment variable.

For example, each paired command will generate Trace2 data of the form:

Control:

    {"event":"def_repo",...,"worktree":"C:/Repos/ScalarFunctionalTests/ControlRepo/4cf6889b5a2b48958e03abb84159e4aa"}
    {"event":"def_param",...,"param":"XXX_TEST_FULLNAME","value":"Scalar.FunctionalTests.Tests.GitCommands.MergeConflictTests(SparseMode).MergeConflict_ThenAbort()"}
    {"event":"def_param",...,"param":"XXX_SEQUENCE_ID","value":"296"}

Enlistment:

    {"event":"def_repo",...,"worktree":"C:/Repos/ScalarFunctionalTests/enlistment/df8748ffc7f74b39aa22/src"}
    {"event":"def_param",...,"param":"XXX_TEST_FULLNAME","value":"Scalar.FunctionalTests.Tests.GitCommands.MergeConflictTests(SparseMode).MergeConflict_ThenAbort()"}
    {"event":"def_param",...,"param":"XXX_SEQUENCE_ID","value":"296"}

Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
@jeffhostetler
Copy link
Contributor Author

TODO Add a note to the code that fsmonitor-daemon processes that are implicitly started by fsmonitor-query-daemon() will inherit the SID of the client command -- which is correct -- but may be misleading when using the long-running or enlistment-per-fixture mode. (I'm assuming that in these modes, the daemon will be started by the first unit test that needs it after the enlistment is created -- rather than having a daemon started per test case.)

Done.

Copy link
Contributor

@derrickstolee derrickstolee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will really help dig out useful logs. Thanks!

@jeffhostetler jeffhostetler merged commit 8a09577 into microsoft:main Jul 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants