Closed bcollamore closed 4 months ago
rouke-broersma
commented
3 years ago Hi bcollamore.
In our experience we cannot do a successful project analysis without a manual nuget restore because buildalyzer does a clean as well. So the clean will have to be disabled as well.
dupdob
commented
4 months ago This feature is not implemented per se, but design and workflow have changed, especially with PR #2975.
Stryker now does dotnet build first and then dotnet msbuild and ultimately an explicit restore if everything else failed.
you can also force using a specific msbuild.exe or msbuild.dll.
Hope this helps
Stryker.NET always performs a 'restore'. CI/CD pipelines may have already performed this step. My specific context: I am trying to run stryker.net in a dockerized GitHub Action. Some projects' nuget.config rely on a private Nuget feed that needs credentials. We do not want to flow the [1..n] set of credentials into this GitHub Action - we want it generic. (The burden is on that repo to sort out how to do a "dotnet restore" independent of Stryker earlier in the pipeline.)
Describe the solution you'd like: A command-line parameter --restore. default to true for backwards compatibility. Support --restore:false. The InputFileAnalyzer's ResolveInput() then constructs an EnvironmentOptions: var environmentOptions = new EnvironmentOptions { Restore = options.Restore }; and passes it to the 2 calls to AnalyzeProject via a new overload that supports an EnvironmentOptions object; that object is passed into BuildAnalyzer's existing Build(EnvironmentOptions) overload.
Additional context: BuildAnalyzer does not appear to support Restore=false in a netcore environment. It always calls "dotnet msbuild" (rather than "dotnet build"), which always does a restore. https://github.com/daveaglick/Buildalyzer/issues/154 filed for this situation.