-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Rev Alpine WithNode from 3.9 to 3.13 #57324
Conversation
Tagging subscribers to this area: @dotnet/runtime-infrastructure Issue DetailsUpdating to 3.14 now will buy us ~2 years before this latest version reaches EOL. Fixes #56672
|
According to https://github.com/dotnet/core/blob/main/release-notes/6.0/supported-os.md#linux, we want to support Alpine 3.13+ for .NET 6. Are binaries built on Alpine 3.14 going to run on Alpine 3.13? |
They should work (as time64 changes were included in 3.13). I will test it. |
Locally I was able to build the main branch without any changes: docker run -v $(pwd):/runtime \
-it mcr.microsoft.com/dotnet-buildtools/prereqs:alpine-3.14-WithNode-20210812132848-d90babf \
/runtime/src/coreclr/build-runtime.sh checked x64 but on CI it was failing to find python while it is clearly there, but when i worked around it, it is now failing with |
@am11 looks like the container doesn't have curl? (and maybe doing the volume mount masks this as you may have a |
I tried with copied IDs from the build logs and I was still able to get the SDK. |
Yes, the docker container |
@am11 please let us know if we can help anyhow. |
@ViktorHofer, it is still a mystery to me as CI error is not reproducible locally. e.g. this leg https://dev.azure.com/dnceng/public/_build/results?buildId=1291489&view=logs&jobId=0e64859c-a870-5a74-6b6e-333fc1003298&j=0e64859c-a870-5a74-6b6e-333fc1003298&t=5da9eef6-c013-592b-ccae-2e46c52786d0 is apparently using container I just (temporarily) deleted runtime/src/coreclr/build-runtime.sh Lines 55 to 58 in 6acb72b
If we test it locally with same command used by this failing CI leg:
it builds coreclr successfully. Do you see anything unusual from the logs that could be causing |
I'll take a look. Let me also cc @safern and @jkoritzinsky |
@hoyosjs @jkoritzinsky any other ideas? I'm currently a bit short on time, maybe you have some additional ideas? |
@MattGal do you think you can help here? |
No guarantees but sure, I'll take a look |
@ViktorHofer I can't reproduce this running main build inside a |
|
Super weird but does seem to be noticed and known externally: dotnet/install-scripts#206. I'm running the same image you used to run the same CI build from a Windows box. I wonder if you started from an Ubuntu 18.04/20.04 if you could get a repro. |
I couldn't repro on a physical Ubuntu box with that container on top. |
Maybe just try |
Flakiness is really not the problem. On other systems, you can build using this new container reliably and in AzDO it is always failing to run build step inside the container (it is apparently running build step on host system rather than the container). Logs are not indicating any problem. |
37bf805
to
2888eaf
Compare
Also, * update helix queues from 3.12 to 3.13 * add 3.14 helix queues * update performance job to install cargo from main branch
174c287
to
7e1fb3e
Compare
@@ -41,15 +41,11 @@ jobs: | |||
|
|||
# Linux musl x64 | |||
- ${{ if eq(parameters.platform, 'Linux_musl_x64') }}: | |||
- ${{ if eq(parameters.jobParameters.isFullMatrix, false) }}: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we test on 3.13 on fullMatrix == true? Meaning on rolling CI?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, didn't mean to press delete on rolling ones 🤣
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks 🎉
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot @am11
It seems like you have a yaml syntax error 😢 : https://dev.azure.com/dnceng/public/_build/results?buildId=1384687&view=results |
There is a JSON failure on Alpine.314.Arm64.Open. @safern do you think the failure is related to the change or we can merge this PR? |
The JSON crash has a dump. We should look at that dump -- there is a how-to-debug-dump.md file there to help. The regex issue is known and fixed already. |
Isn't it #57198? |
I think we should at least look at the dump to make sure if it is: #57198 before merging something that could potentially introduce a failure to CI. |
The dump link on that issue is expired and Eirik had no success with Maybe rerun the job to see if the issue persist? |
Sounds good to me. |
Ah gotcha. Is there anything that can be gotten out of this dump? |
I am working on it. 🙂 |
|
Sounds like both test failures are known and tracked/fixed already. Can we merge this PR? |
Also,
Fixes #56672