Make build more coherent with same "dotnet sdk" on all CI machine. #396
Conversation
| @@ -0,0 +1,71 @@ | |||
| # Resolve any symlinks in the given path. | |||
There was a problem hiding this comment.
took idea from corefx repo
| wget -q -O "$install_script" "$install_script_url" | ||
| fi | ||
|
|
||
| bash "$install_script" --version 2.2.203 --install-dir "$dotnet_root" || { |
There was a problem hiding this comment.
we could move version in a simple text file on eng folder and take version from there.
| Create-Directory $toolsRoot | ||
| $scriptPath = Join-Path $toolsRoot "dotnet-install.ps1" | ||
| Invoke-WebRequest "https://dot.net/v1/dotnet-install.ps1" -OutFile $scriptPath | ||
| & $toolsRoot\dotnet-install.ps1 -InstallDir $toolsRoot\dotnet -Version 2.2.203 |
There was a problem hiding this comment.
we could move version in a simple text file on eng folder and take version from there.
Codecov Report
@@ Coverage Diff @@
## master #396 +/- ##
==========================================
+ Coverage 85.85% 86.98% +1.12%
==========================================
Files 17 16 -1
Lines 2234 2182 -52
==========================================
- Hits 1918 1898 -20
+ Misses 316 284 -32 |
MarcoRossignoli
force-pushed
the
newbuild
branch
3 times, most recently
from
f9c2d6c to
ef60fb2
Compare
|
@tonerdo seems work, I moved docs under Documentation in line with |
|
@tonerdo we should move to AzurePipelines https://azure.microsoft.com/en-us/blog/announcing-azure-pipelines-with-unlimited-ci-cd-minutes-for-open-source/ |
|
Another plus of this approach is that we can run CI on a list of SDK which could produce different IL and invalidate code assumptions and again in future we could have different instrumentation related to different SDK(we can read it runtime). |
|
@tonerdo PTAL |
|
@tonerdo merged and fixed azp |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
@tonerdo woot command works! |
|
@tonerdo I think it's ready to go! |
|
I wonder if you're trying too hard. Your repo's build requirements really aren't that strange to justify all these custom build scripts. Add a global.json file to your repo to "pin" the right .NET Core SDK used to build with. Here's an example. Then modify your azure pipelines YAML file to install that version. Here's an example. |
|
@AArnott the idea of download sdk is for future use...I mean instrumenting code and verify coverage depends on compiler version, different version of compilers generage different pdb and in future we would like to have a way to run tests with more than one sdk version...for instance take a look at this PR #389 #390 behaviour of hide sequence point is changed and our tests started to fail. |
|
Here's what it looks like in full for your repo Disclaimer: not fully tested yet. |
|
It's now tested. |
|
@AArnott do you have better way to provide a CI with more than one SDK(locally runnable)? |
|
Yes, I think we can handle that too. My personal recommendation is that you build with exactly one SDK version (that you've pinned for consistency). Then you test on as many SDKs as you need your coverlet build extension to support for your target customers. |
|
Now CI depends on custom sdk that is one of the goal of this PR. |
Related to #390 (comment)
We have two script
They download sdk to
reporoot\.tools\and run dotnet cli from there, this should lead to more coherent build/test result because build is "machine dotnet runtime version agnostic"./cc @tonerdo @petli