-
Notifications
You must be signed in to change notification settings - Fork 17
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
hardcode dotnet version #20
Conversation
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.
If we go this way instead of runDotNet
, we should probably just remove that utility function and use DotNetCli.Test
in the other call site.
Concievably, we could create a default config mutator which we chain with the mutator here, to set e.g. tool path and configuration in a single place.
let defaultConfig config = { c with Configuration = "release"; ToolPath = dotnetCliPath }
// ...
DotNetCli.Build defaultConfig
DotNetCli.Test (defaultConfig >> fun c -> { c with SomeOtherSetting = "changed" })
Note that without changing the toolspath in the test call site, the build will fail there with the same error as the one this attempts to solve (this is currently handled by runDotNet
).
@fbehrens It's in |
ok let me PR it to FAKE 5 |
@tlycken Totally agree, I do not have much knowledge about how all this is properly done with |
the error message of the failed build on travis for our self-contained-hello-world is
in https://github.com/dotnet/cli/issues/3390 it's said that |
We can install dependencies in Travis before we start the build. In short, add the following to
If any other packages are needed too, just list them, space-separated, after the command above. |
I'm strongly against such an approach; one of the fundamental properties of a build script/build pipeline is that it's useless as soon as it's "magic". In that case, it's much better if we can ensure that it's so dead-simple that we all understand how it works. That said, looking at other build scripts to see how they solve specific problems is, of course, not a problem; I just don't want the build script to include anything we don't need and aren't using. |
Nice! The previous build error seems to have been a temporary glitch (from what I could understand in the build log, NuGet failed to respond). Restarting the build solved it. And with that, we have working CI builds on Windows and Linux - thanks a lot, @fbehrens! 🎉 |
This also fixes #19. |
Yay! |
maybe this is a fix for #19.
If it works next question would be where to get or store the dotnet-version.