Mono support

[asbjornu]

TODO

• Merge and pre-release Mono support GitTools.Testing#2 on NuGet.
• Update to the above pre-release of GitTools.Testing.
• Fix the tests now failing with System.ArgumentNullException : Value cannot be null. Parameter name: source at System.Linq.Enumerable.ToArray[TSource] (IEnumerable1 source)`
• Fix IO related failing tests.
• Fix the tests asserting the wrong temporary path.
• Fix tests failing with EntryPointNotFoundException due to SetErrorMode() not being supported on Mono.

Overview

This PR adds a Travis build to ensure Linux/Mono compatibility and upgrades LibGit2Sharp to version 0.23.0-pre20150419160303 so we get the fixes in libgit2/libgit2sharp#1298.

GitTools.Testing

This PR depends on GitTools/GitTools.Testing#2 needs to be merged and released on NuGet, so that dependency can be updated.

When all of the above is figured out and fixed, it would be nice to have this merged and pre-released on NuGet, so I can go on to update GitVersion as well.

[asbjornu]

@JakeGinnivan The only thing left to fix now are two tests failing on Travis (Linux) with something like this:

The provided expression
    should be
"/tmp/.git"
    but was
"/tmp/_4/.git"

On OS X they fail with something along these lines:

The provided expression
    should be
"/var/folders/_t/hkn5jvjd6blcf9tf8zv5cx8c0000gn/T/.git"
    but was
"/private/var/folders/_t/hkn5jvjd6blcf9tf8zv5cx8c0000gn/T/_5/.git"

Seems like Path.GetTempPath() returning a symlink on OS X is still a problem although mono/maccore#42 was merged 3 years ago.

Do you have any idea how we can make these temporary path tests a little more robust?

[dazinator]

Was just curious to know the reason behind using the temp directory.. why not force a directory to be specified, or default to the current working dir?

[asbjornu]

@dazinator I think using temporary paths for testing is reasonable. Hard coding a path would be difficult to get right across different build environments, don't you agree? What I'm unsure of, is why the path is asserted in the first place. I don't understand the semantics of the assertion, so I'm unable to figure out another way to do it. Only @JakeGinnivan can help out there, I think.

[dazinator]

@asbjornu - perhaps i'm mistaken but I would have thought using a path thats relative to the test projects output directory wouldn't be too difficult, and would avoid the use of the temp directory. I dont think the temp dir is bad per say, but Ive always preferred to keep assets under the checkout / working dir and not use global / system / shared directories when it can be avoided!

[asbjornu]

@dazinator Good point. If you have time to spare, do you think you could contribute some time to fixing this in the few tests that are failing? You don't need to do a PR or anything; just fork the branch of this PR and push your stuff to your fork and I'll pull it into this PR after. That would be very much appreciated! ❤️

[dazinator]

@asbjornu - The tests seem to fail because they are a little brittle.

Basically in the failing test - this happens

GitTools.Tests.Git.GitRepositoryFactoryTests.PicksAnotherDirectoryNameWhenDynamicRepoFolderTaken

Basically this tries to establish a folder name in the temp directory for the repo, based on the repo name. If the folder name is already taken it recursively appends a number - _N to the path and checks again, until it finds a folder name that that is available to put the repo.

The test is not expecting this to happen. So it expects it to be placed in the temp dir, without this number being appended to the path, but because on the system that is running the tests, the temp dir is probably polluted, it ends up not using the expected folder, and creates a unique folder by appending this number to the path instead.

So it's actually doing what it is meant to do, but the test is brittle and fails it.

This probably lends wait to the hazard of using system / global / shared directories during tests and not keeping things isolated!

I think it makes sense to switch away from using the temp dir as I have mentioned previously, but such a change would potentially impact GitVersion, so I have raised an issue over there to figure out what the consequence is if we swtiched: GitTools/GitVersion#822

Once that's clarified, i'd be happy to contribute :)

[asbjornu]

@dazinator I've ignored the failing tests in #31, but you're more than welcome to submit a PR that un-ignores the tests and fixes the underlying problem! 👍