Skip to content

[ci] Move Windows build and test to VS2019 - #3552

Merged
jonpryor merged 7 commits into
dotnet:masterfrom
pjcollins:win-build-test-2019
Aug 30, 2019
Merged

[ci] Move Windows build and test to VS2019#3552
jonpryor merged 7 commits into
dotnet:masterfrom
pjcollins:win-build-test-2019

Conversation

@pjcollins

@pjcollinspjcollins commented Aug 26, 2019

Copy link
Copy Markdown
Member

We've been encountering a handful of issues recently with the Windows
machine pool we're using for building and testing. There have been quite
a few failures caused by files being locked, or dependencies being out
of date or missing. Moving to the VSEng VS2019 Windows pool will
hopefully resolve some of these issues.

Unfortunately the size of our build dependencies presents an issue when
attempting to use the Microsoft hosted Windows VS2019 agents, as our Win
job ultimately runs out of space when executing on those VMS. Using the
VSEng VS2019 pool will allow us to migrate to VS2019 while avoiding disk
space limitations.

As of commit 8cdda11, $(JavaSdkDirectory) will have a default value
of the path to the Corretto JDK we install on both Windows and macOS.
We should try to use this JDK path for all Android/Java tool invocations
which require $(JAVA_HOME) to be set.

Also adds a process monitor/killer to our Windows build jobs to attempt
to better monitor, or hopefully prevent, cases of our source directory being
in use by an external process when a job starts.

@pjcollinspjcollins added the do-not-merge PR should not be merged. label Aug 26, 2019
We've been encountering a handful of issues recently with the Windows
machine pool we're using for building and testing. There have been quite
a few failures caused by files being locked, or dependencies being out
of date or missing. Moving to the VSEng VS2019 Windows pool will
hopefully resolve some of these issues.
Unfortunately the size of our build dependencies presents an issue when
attempting to use the Microsoft hosted Windows VS2019 agents, as our Win
job ultimately runs out of space when executing on those VMS. Using the
VSEng VS2019 pool will allow us to migrate to VS2019 while avoiding disk
space limitations.
@pjcollinspjcollins changed the title [ci] Move Windows build and test to hosted VS2019[ci] Move Windows build and test to VS2019Aug 28, 2019
pjcollinsand others added 5 commits August 28, 2019 16:15
As of commit 8cdda11, `$(JavaSdkDirectory)` will have a default value
of the path to the Corretto JDK we install on both Windows and macOS.
We should try to use this JDK path for all Android/Java tool invocations
which require `$(JAVA_HOME)` to be set.
Versions 2+ of .NET Core are installed into `C:\Program Files\dotnet`
rather than `C:\Program Files (x86)\Microsoft Visual Studio\$(Version)`.
@pjcollinspjcollins removed the do-not-merge PR should not be merged. label Aug 30, 2019
@pjcollins

Copy link
Copy Markdown
MemberAuthor

@dellis1972@jonathanpeppers This should hopefully be ready to go now.

@jonpryor
jonpryor merged commit 7f9c4b8 into dotnet:masterAug 30, 2019
jonpryor pushed a commit that referenced this pull request Sep 4, 2019
We've been encountering a handful of issues recently with the Windows
machine pool we're using for building and testing. There have been
quite a few failures caused by files being locked, or dependencies
being out of date or missing, or CS8107 errors on the
[mono/2019-08 bump PR][0] because source code is using C#7.1 features:
external\linker\src\linker\Linker.Steps\MarkStep.cs(2272,19): Error CS8107: Feature 'default literal' is not available in C# 7.0. Please use language version 7.1 or greater.
[0]: #3449
Moving to the VSEng VS2019 Windows pool will hopefully resolve some
of these issues.
Unfortunately the size of our build dependencies presents an issue
when attempting to use the Microsoft hosted Windows VS2019 agents, as
our Win job ultimately runs out of space when executing on those VMS.
Using the VSEng VS2019 pool will allow us to migrate to VS2019 while
avoiding disk space limitations.
Additionally, as of commit 8cdda11, `$(JavaSdkDirectory)` will have
a default value of the path to the Corretto JDK we install on both
Windows and macOS. We should try to use this JDK path for all
Android/Java tool invocations which require `$(JAVA_HOME)` to be set.
Finally, remove the `Builder.MicrosoftNetSdkDirectory` property and
related attempts to find the .NET Core SDK path, as
`azure-pipelines.yaml` now explicitly installs our required
.NET Core SDK version.
@github-actionsgithub-actionsBot locked and limited conversation to collaborators Jan 29, 2024
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants

@pjcollins@dellis1972@jonathanpeppers@jonpryor