Skip to content

Explicitly set xUnit MSBuild WorkingFolder property #1139

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

Merged
merged 1 commit into from
Jul 5, 2015

Conversation

bording
Copy link
Member

@bording bording commented Jul 4, 2015

Looking at the Travis failure @nulltoken pointed out in #1138, I noticed that when it fails, it was looking for
/home/travis/build/libgit2/Resources/testrepo.git

which is not even in the same folder as the source code! It should be looking for

/home/travis/build/libgit2/libgit2sharp/LibGit2Sharp.Tests/Resources/testrepo.git

All of the test repo paths are build like this: ../../Resources/testrepo.git so looks like xUnit is sometimes changing its working folder in the middle of testing?

I could reproduce this on my local ubuntu VM, which is running mono 3.12.1, same as Travis.
However, on my mac, I have mono 4.0.2 and it ran perfectly. Same for Windows.

I have another VM running CentOS and mono 4.0.2, and after getting the tests running there... it also ran without errors!

It seems that the xUnit.net 2.0 MSBuild test runner does not play nicely with mono 3.12.1, which is being used on the linux Travis CI builds.

Looking through the xUnit docs, I saw that there is a WorkingFolder property that can be set explicitly instead of relying on the default value. After setting that value, the failures on mono 3.12.1 seem to have vanished.

It seems that the xUnit.net 2.0 MSBuild test runner does not play nicely
with mono 3.12.1, which is being used on the linux Travis CI builds.

Setting this property appears to stop the intermittent failures by
preventing xUnit from forgetting how to find the Resources folder in the
middle of running the tests.
@bording
Copy link
Member Author

bording commented Jul 4, 2015

And, looks like everything passed!

Seems like this should work around the issue as long as we're not having Travis use mono 4.

nulltoken added a commit that referenced this pull request Jul 5, 2015
Explicitly set xUnit MSBuild WorkingFolder property
@nulltoken nulltoken merged commit a07186e into vNext Jul 5, 2015
@nulltoken nulltoken deleted the bording/fixTravisBuilds branch July 5, 2015 12:43
@nulltoken
Copy link
Member

you-rock

@nulltoken nulltoken added this to the v0.22 milestone Jul 8, 2015
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.

2 participants