Add .NET6 to CI scripts#1605
Add .NET6 to CI scripts#1605gregkalapos merged 22 commits intoelastic:mainfrom gregkalapos:InstallDotNet6InCi
Conversation
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
🤖 GitHub commentsTo re-run your PR in the CI, just comment with:
|
.NET 6 SDK isn't happy with the `;`
|
|
||
| dotnet nuget add source --name nuget.org https://api.nuget.org/v3/index.json | ||
|
|
||
| :: Build solution. Add `--verbosity detailed` for more detailed logs |
There was a problem hiding this comment.
Took out verbose logging - it turned out to generate huge noise when I need to look at logs from a failed build. I'd prefer to keep it without verbose logs and only turn it on once we really need it.
| # Install visualstudio2019 and workloads needed to build ASP.NET and .NET Core apps | ||
| Invoke-WebRequest -UseBasicParsing ` | ||
| -Uri "https://download.visualstudio.microsoft.com/download/pr/cb1d5164-e767-4886-8955-2df3a7c816a8/b9ff67da6d68d6a653a612fd401283cc213b4ec4bae349dd3d9199659a7d9354/vs_BuildTools.exe" ` | ||
| -Uri "https://download.visualstudio.microsoft.com/download/pr/ce8663b0-08ed-410a-9f5d-4f9469d1b2cb/73271b3d53a4e50e65e2e918a8c1100d2681c17bc418e03513c9f0554609ff8a/vs_BuildTools.exe" ` |
There was a problem hiding this comment.
This updates it to the vs 2022 version.
| dir("${BASE_DIR}"){ | ||
| powershell label: 'Install test tools', script: '.ci\\windows\\test-tools.ps1' | ||
| retry(3) { | ||
| bat label: 'Build', script: '.ci/windows/dotnet.bat' |
There was a problem hiding this comment.
Instead of building it once and then running test.bat in a separate step we can do the whole thing in test.bat.
|
elastic/apm-integration-testing#1412 takes care of failing integration tests. |
| :: LogFilePath property | ||
| :: | ||
| dotnet test -c Release --no-build ^ | ||
| dotnet test -c Release ^ |
There was a problem hiding this comment.
Out of curiosity, if the test.bat does also run the build, are the dotnet sln remove needed for the building?
There was a problem hiding this comment.
Yes, that's intentional.
Those projects that we remove with dotnet sln remove need more than what we have in this context (e.g. ASP.NET Classic), so the dotnet tool isn't enough for those. We use those projects in the Windows .NET Framework stage.
I only know this from experience. If we don't remove those, it'll fail - I saw it :) . Prior to this PR removing happened in the dotnet.bat file.
There was a problem hiding this comment.
Thanks Greg for the clarification :)
3 participants
Solves #1566