-
Notifications
You must be signed in to change notification settings - Fork 347
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
NuGet failing with Response status code does not indicate success: 503 (Service Unavailable) #11723
Comments
Updated an ErrorMessage |
This error message is too specific. The package name does not matter for 503 errors. You can see it in the log file attached to this issue. The build failure was caused by multiple different packages failing to be retrieved - for example, look for |
Yeh, most probably |
15 hits in the last 24 hours, I'm going to enable build retry |
Created IcM to ask for investigation here as well, https://portal.microsofticm.com/imp/v3/incidents/details/353857134/home |
More hits today. Update from the IcM: "Will check throttling limits to see if that's kicking in here" |
I updated the ICM and received no response from them. |
Where are 500s from the public AzDO feeds tracked❔ I don't see efcore-ci build #20230213.2 mentioned here for example. That build matches the |
Does the EFCore repo uses build analysis? Known issues tracking is part of build analysis |
Might need a separate Known Build Error for the
Affected aspnetcore-ci rolling builds over the last week: |
No. /cc @bricelam and @ajcvickers because I don't remember why they didn't opt in and don't know if those reasons remain valid. |
Would that issue have picked up the efcore-ci failure given it occurred in a rolling build (where build analysis isn't relevant) for a repo where build analysis isn't enabled anyhow❔ |
In any case, the |
Oh, ignore my last comment. You were talking about the |
Side note: The Known Build Errors infrastructure is tilted pretty far toward PR failures. It's far too manual (AFAICT) to use for rolling build failures and the https://msit.powerbi.com/groups/de8c4cb8-b06d-4af8-8609-3182bb4bdc7c/reports/f0702582-7c04-47ca-a145-6ac37fd25813/ReportSectioncb62e8e5baebca8883e1?experience=power-bi doesn't seem to automatically report matches for such issues (nor help enough in creating them). |
Correct I was keying off you talking about "pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-public-npm/npm/registry/istanbul-lib-report/-/istanbul-lib-report-3.0.0.tgz" since that's not nuget-y |
@AlitzelMendez - any feedback here? |
@ilyas1974 assigning this to you, cos you were looking at a similar issue |
so after some months I saw this comment :) I think we explored this option in the past but I never found the dashboard in which we wanted to add a link to create known issue, but I think is a great and reasonable idea. reopening: #8794 |
Build
https://dev.azure.com/dnceng-public/public/_build/results?buildId=300923&view=results
Build leg reported
Build / Installer Build and Test coreclr windows_x86 Debug / Build
Pull Request
dotnet/runtime#78801
Action required for the engineering services team
To triage this issue (First Responder / @dotnet/dnceng):
If this is an issue that is causing build breaks across multiple builds and would get benefit from being listed on the build analysis check, follow the next steps:
Release Note Category
Release Note Description
Additional information about the issue reported
No response
Report
Summary
Known issue validation
Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=300923
Result validation: ✅ Known issue matched with the provided build.
The text was updated successfully, but these errors were encountered: