-
Notifications
You must be signed in to change notification settings - Fork 188
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
feat: use buildalyzer to identify source files #898
Conversation
/azp run (it was worth a try) |
Commenter does not have sufficient privileges for PR 898 in repo stryker-mutator/stryker-net |
1 similar comment
Commenter does not have sufficient privileges for PR 898 in repo stryker-mutator/stryker-net |
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
Sorry :p You need permission on azure devops to be able to do that. |
FYI: I have constant issues with nuget (error nu1403, hash changed), hence I have to juggle with packages.lock.json.
|
@dupdob That issue is due to a bug in previous versions of dotnet core... :( See: NuGet/Home#7921 (comment) Luckily this is only an issue if you have previously contributed to stryker. Something with the hashes being calculated wrong in something called 'NugetFallbackLocation' which keeps being an issue if you have ever had packages downloaded into there.. These steps should help you fix it for your system:
|
src/Stryker.Core/Stryker.Core/Initialisation/InputFileResolver.cs
Outdated
Show resolved
Hide resolved
Could you add some unit tests for the InputFileResolver? It contains a lot of new code that seems important 😄 |
# Conflicts: # src/Stryker.Core/Stryker.Core/Initialisation/InputFileResolver.cs
Added a unit test |
src/Stryker.Core/Stryker.Core.UnitTest/Initialisation/InputFileResolverTests.cs
Show resolved
Hide resolved
The code looks good but the build seems to fail on linux? I'll try running again to see if it was a random encounter |
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
I have tested your code on a project and indeed I see buildalyzer provides a set of files. I don't know why it didnt work when I tried a few weeks ago. But that is great news 🎉 |
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
it looks a random event, since previous run (with the weak unit test) ran fine. |
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
👏 |
Fix #897. No unit tests due to an exploration based approach.
Old scanning logic still present in case buildalyzer completely fails