[CI] Add Linux Build and Smoke Test job #5681
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
pjcollins
force-pushed
the
pack-linux
branch
4 times, most recently
from
7fd0a6a to
fb6222b
Compare
Member
Author
|
Of the 19 remaining MSBuild smoke test failures, the AppBundle tests are failing to build with: While the rest fail with: |
Context: https://dev.azure.com/devdiv/DevDiv/_build/results?buildId=4518058&view=logs&j=8100f0f7-e86c-5b6e-6a78-6808e1478ee9&t=b2ff00a9-cb72-5405-b714-ea139eccf107&l=482 Failed CheckSignApk(True,False) [27 ms] Error Message: System.InvalidOperationException : Could not determine Java SDK location. Please provide `javaSdkPath`. Stack Trace: at Xamarin.Android.Tools.AndroidSdkInfo..ctor(Action`2 logger, String androidSdkPath, String androidNdkPath, String javaSdkPath) in /agent/_work/1/s/xamarin-android/external/xamarin-android-tools/src/Xamarin.Android.Tools.AndroidSdk/AndroidSdkInfo.cs:line 25 at Xamarin.Android.Build.Tests.PackagingTest.CheckSignApk(Boolean useApkSigner, Boolean perAbiApk) in /agent/_work/1/s/xamarin-android/src/Xamarin.Android.Build.Tasks/Tests/Xamarin.Android.Build.Tests/PackagingTest.cs:line 366 The new Ubuntu test machines do not have JAVA_HOME set (or any other fallback mechanism for locating the JDK). When creating a new instance of AndroidSdkInfo we should pass the JDK value used by the tests. In other cases, we can avoid creating an AndroidSdkInfo object entirely as it was only being used to get a JDK path.
Member
Author
|
I've cut smoke test scope in the latest force push to hopefully get this green. This gives us the option to investigate and fix various Linux issues at a later date. |
pjcollins
requested review from
dellis1972,
grendello,
jonathanpeppers and
jonpryor
Member
Author
|
I've got a "commercial" Linux build and a few tests working here. I'm wondering if it's worth getting this in now and investigating and fixing test issues in future PRs, or if we want to try to get those fixed as part of this PR to increase test coverage before landing this build? |
Contributor
I think it's better to delay the fixes till some point in the future, and commit the PR as it is now. |
grendello
approved these changes
Mar 5, 2021
Contributor
|
/azp run |
Contributor
|
Not sure why, but the upload test assemblies step failed repeatedly. Restarted the build. |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Member
Author
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Member
Author
|
I've updated the build pool to use a new VMSS named |
jonathanpeppers
approved these changes
Mar 10, 2021
dellis1972
approved these changes
Mar 10, 2021
pjcollins
added a commit
that referenced
this pull request
Jan 5, 2022
Bumps to mono/debugger-libs@c53676b Changes: mono/debugger-libs@08268b7...c53676b Many instances of `msbuild` have been replaced with `dotnet build` in our make files. The `-m:1` flag has been added to `Xamarin.Android.sln` builds to disable parallelization. We still run into issues running `dotnet build` on the .sln when this flag is not used. Additionally, `msbuild` is still required when building `xabuild.csproj` and `create-vsix.csproj`. The `make jenkins` target has been updated to no longer create an OSS .zip file to improve build speeds. OSS installers can be built separately as needed. The `Xamarin.Android.Build.Tasks` build has been updated to run ILRepack on Linux to fix [various issues][0]. A new `MonoUnixNative.targets` file has been added that can be used by projects that produce an assembly containing MSBuild tasks that depend on Mono.Unix. The `<_MakeMonoUnixFatBinariesOSX/>` target will create a multiarchitecture version of `libMono.Unix.dylib` in the projects output directory when running on macOS. It will also copy `runtimes\linux-x64\native\libMono.Unix.so` and `runtimes\osx-x64\native\libMono.Unix.dylib` to the output directory when running on Windows or Linux. [0]: #5681 (comment)
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A new Linux Build + Smoke test job has been added to produce a
"commercial" .NET 6 Linux SDK .nupkg. This job takes advantage of a new
Azure Virtual Machine Scale Set pool that has been created
specifically for this job. This VMSS can be found in the Azure portal
under the name xaubuntu20.04-vmss.
This job is configured to run the
PackagingTest.CheckSignApktests, asubset of the broader smoke test category. More tests should be added
to this job in the future as needed. The execution of these tests on
this new build pool exposed a test framework issue that occurs on
environments that do not export
$JAVA_HOME, or have a JDK installationin any default look up paths:
To avoid this, we can pass the JDK path used by the tests when creating
new instances of AndroidSdkInfo. In some of these cases AndroidSdkInfo
was only being used to calculate a JDK path for a tool that a test
needed, and in these cases we can use AndroidSdkResolver.GetJavaSdkPath
directly.