Skip to content
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

Add Alpine CI for source-build #14417

Merged
merged 4 commits into from Feb 22, 2023

Conversation

omajid
Copy link
Member

@omajid omajid commented Aug 29, 2022

No description provided.

@MichaelSimons MichaelSimons changed the base branch from main to release/7.0.1xx August 31, 2022 13:58
@MichaelSimons MichaelSimons changed the base branch from release/7.0.1xx to main August 31, 2022 13:58
@MichaelSimons
Copy link
Member

@omajid, can you please rebase and target release/7.0.1xx? This will automatically flow back to main. Right now we are waiting on a new xliff version to fix the build failure this offline leg encountered.

@omajid omajid changed the base branch from main to release/7.0.1xx August 31, 2022 17:46
@omajid omajid force-pushed the source-build-alpine-ci branch 7 times, most recently from 0785d67 to 0b30cde Compare September 6, 2022 18:43
@omajid
Copy link
Member Author

omajid commented Sep 6, 2022

The build is failing with this error:

/tarball/src/roslyn/artifacts/source-build/self/src/src/Tools/Source/CompilerGeneratorTools/Source/CSharpSyntaxGenerator/CSharpSyntaxGenerator.csproj : error NU1102: Unable to find package Microsoft.NETCore.App.Host.linux-musl-x64 with version (= 6.0.8) [/tarball/src/roslyn/artifacts/source-build/self/src/Roslyn.sln]

Would it be better to wait for fixes to flow in to remove this dependency on 6.0.x? Or should I look at adding linux-musl-x64 assets to the prebuilt tarball too?

@MichaelSimons
Copy link
Member

Would it be better to wait for fixes to flow in to remove this dependency on 6.0.x?

We should wait until the 6.0 tfm related prebuilts are removed which is slated for RC2.

@MichaelSimons
Copy link
Member

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@omajid omajid force-pushed the source-build-alpine-ci branch 2 times, most recently from c44e0ec to a32c96c Compare September 22, 2022 22:44
@omajid
Copy link
Member Author

omajid commented Sep 23, 2022

@lbussell was right! We were completely missing PackageDownload for some packages.

@MichaelSimons any idea what version variable I can use for runtime.linux-x64.Microsoft.NETCore.Runtime.ObjWriter? It doesn't appear to be in Private.SourceBuilt.Artifacts.7.0.100-rc.1.tar.gz's PackageVersions.props.

@MichaelSimons
Copy link
Member

Looks like you can reference it by RuntimeLinuxX64MicrosoftNETCoreRuntimeObjWriterVersion.

@@ -24,6 +28,7 @@
<PackageDownload Include="runtime.linux-x64.runtime.native.System.IO.Ports" Version="[$(RuntimeLinuxX64RuntimeNativeSystemIOPortsVersion)]" />
<PackageDownload Include="runtime.linux-musl-x64.Microsoft.NETCore.ILAsm" Version="[$(RuntimeLinuxX64MicrosoftNETCoreILAsmVersion)]" />
<PackageDownload Include="runtime.linux-musl-x64.Microsoft.NETCore.ILDAsm" Version="[$(RuntimeLinuxX64MicrosoftNETCoreILDAsmVersion)]" />
<PackageDownload Include="runtime.linux-musl-x64.Microsoft.NETCore.ObjWriter" Version="[$(RuntimeLinuxX64MicrosoftNETCoreRuntimeObjWriterVersion)]" />
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The ObjWriter dependency has been removed. This is no longer necessary.

@crummel
Copy link
Contributor

crummel commented Oct 14, 2022

I added my fix from #14769 here so hopefully that should fix the ASP.NET package version issue.

@ayakael
Copy link
Contributor

ayakael commented Nov 28, 2022

@omajid I'd like to contribute to this PR now that dotnet7 is merged. It would be incredible useful for me, as we can track issues as they pop up rather than when I attack new releases with release candidates. It would also be useful to have an alpine mono build. Could I have write access as to work on it?

@ayakael
Copy link
Contributor

ayakael commented Nov 28, 2022

By the way, the current issues will be fixed once #14549 is backported to release/7.0.1xx. We will encounter another issue, though, as it is still necessary to set /p:OSName=linux-musl and /p:HostOSName=linux-musl when building on Alpine. We'll need to branch off of #13410 to set those flags when musl is detected.

edit
This will apply to once we start working on allowing source-build to build portable builds, but that's a future-us problem.

2nd edit the issue with HostOSName and OSName seems to be fixed now that NETCoreSdkPortableRuntimeIdentifier is well defined due to fixing --use-current-runtime

@omajid
Copy link
Member Author

omajid commented Feb 8, 2023

@ayakael sorry about missing your message earlier. I am happy to give you commit access to this PR. Do you know how I can do that?

@omajid
Copy link
Member Author

omajid commented Feb 8, 2023

The darwin error doesn't look related?

@MichaelSimons
Copy link
Member

The darwin error doesn't look related?

Yes that is a known issue.

@MichaelSimons
Copy link
Member

Great to see this is passing. Thanks to all who contributed on Alpine! Is this "ready for review" after switching alpine to be a non-PR leg?

@omajid omajid marked this pull request as ready for review February 8, 2023 21:26
@omajid omajid requested a review from a team as a code owner February 8, 2023 21:26
@omajid
Copy link
Member Author

omajid commented Feb 8, 2023

We don't seem to have non-helix Alpine 3.16 or newer in our pre-reqs containers. Is 3.15 enough? Should we look at any other versions?

@MichaelSimons
Copy link
Member

Is 3.15 enough? Should we look at any other versions?

Ideally we would pick a version supported throughout the 7.0 lifecycle (EOL May 2024), so yes I think we should look at adding the required buildtools-prereqs images. If we are going to the work of adding one, the highest ROI seems like it would be adding 3.17 images.

omajid added a commit to omajid/dotnet-buildtools-prereqs-docker that referenced this pull request Feb 10, 2023
This came up in dotnet/installer#14417. We are
trying to add a CI leg for alpine, and alpine 3.17 most closely matches
the 7.0.1xx lifecycle.

The Dockerfile itself is a copy of the 3.15 Dockerfile, with 3.15
replaced with 3.17.
omajid added a commit to omajid/dotnet-buildtools-prereqs-docker that referenced this pull request Feb 10, 2023
This came up in dotnet/installer#14417. We are
trying to add a CI leg for alpine, and alpine 3.17 most closely matches
the 7.0.1xx lifecycle.

The Dockerfile itself is a copy of the 3.15 Dockerfile, with 3.15
replaced with 3.17.
@omajid omajid force-pushed the source-build-alpine-ci branch 3 times, most recently from e13a2f8 to 885bd82 Compare February 15, 2023 15:36
@omajid
Copy link
Member Author

omajid commented Feb 16, 2023

The failure is in the non-source-build leg, which uses alpine 3.15. That seems unrelated to my PR...

@omajid
Copy link
Member Author

omajid commented Feb 16, 2023

Yup, same errors here: #15559. I am going to ignore these non-source-build errors and fix up the PR for merging.

It's the release that most closely matches the .NET 7.0 lifetime.
@MichaelSimons
Copy link
Member

@omajid - thanks for this contribution. I will merge after the branch opens.

@MichaelSimons MichaelSimons enabled auto-merge (squash) February 22, 2023 15:51
@MichaelSimons MichaelSimons merged commit df0fc12 into dotnet:release/7.0.1xx Feb 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants