-
Notifications
You must be signed in to change notification settings - Fork 899
Upgrade development dependencies #1138
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
Conversation
8e56dae
to
2e5e030
Compare
👍 |
Upgrade development dependencies
@@ -56,8 +56,10 @@ private static void SetUpTestEnvironment() | |||
{ | |||
IsFileSystemCaseSensitive = IsFileSystemCaseSensitiveInternal(); | |||
|
|||
string initialAssemblyParentFolder = Directory.GetParent(new Uri(Assembly.GetExecutingAssembly().EscapedCodeBase).LocalPath).FullName; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/cc @cmn @bording @Therzok This change somehow bit me in the back. During the last hour I've randomly seen passing/failing build runs on Travis due to this. Any idea? 🙏
Latest failure is at https://travis-ci.org/libgit2/libgit2sharp/jobs/69555887
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are so many parts here that have changed in a short period of time, I'm not sure where to start!
@nulltoken In addition to the xunit 2.0 changes here, I see that you've also bumped up to a NativeBinaries package that includes the changes I made there recently, and it also has a new libgit2 version along with my changes.
Any idea when the failures started? Before or after the new NativeBinaries update?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problems come from the fixture not being able to find the resources path. It ends up deleting two components from the path, which indicates that it's taking the source dir path instead of where the dll is located as the first path.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This started strangely with this very PR. Before the merge, everything was green. Once merge vNext failed on Travis/Mac with the same mangled path error. I restarted the build and... It passed. In the native binaries PR, I've tried to change the way the assembly location was identified. This seemed to be working.... Until this one. It looks like everything is related to xUnit shadow copying. IIRC you introduced this because of an issue I cannot remember of.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I think I've figured out what's going on here. PR with more details coming soon!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❤️
No description provided.