-
Notifications
You must be signed in to change notification settings - Fork 446
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
[main] Rebootstrap with latest changes #19145
Conversation
Will update with latest installer build to pick up newer publishing changes. |
Updated with SDK from the latest |
As a general rule, if the SDK is updated the PSBs should also be updated as well. This eliminates potential headaches caused by the mismatch. |
Yeah, working on it - using this build: https://dev.azure.com/dnceng/internal/_build/results?buildId=2411637&view=results |
Hmm, failing to bootstrap, as SDK is not available - will need to update with a different build. |
None of the newer installer builds are publishing assets. @ViktorHofer @mmitche I've reverted to original PR changes. |
This is because of the 1ES template migration: #19016 (comment) |
Sounds like #19016 (comment) got resolved. Can we re-bootstrap with a newer SDK so that we include all the publishing changes? |
Submitted dotnet/winforms#11122 to fix the new analyzer warning. This could be patched to unblock this PR until the fix flows into installer. |
I've refreshed this PR with latest builds (from this morning). I've updated the first comment to reflect the asset sources. Validation build is still running (stage 2 legs) - everything is green so far. |
@NikolaMilosavljevic - Please create a patch for @ViktorHofer dotnet/winforms#11122 to unblock this bootstrap. I'd like to get our full build green again. |
Sure - will do. Source-build validation was all green: https://dev.azure.com/dnceng/internal/_build/results?buildId=2414987&view=results |
I think that dotnet/sdk#39782 already contains the fix. This might just be a matter of waiting for another 2 hours until the change is merged into installer main. Just saying, as resolving patches also adds noise to dependency flow. |
Two hours is pretty optimistic IMO. I do hear you though on resolving patches. Given this is blocking other work, my preference is to merge this PR and have be proactive on removing the patch in the dependency flow. |
I don't think SDK flow contains the fix. Winforms did not flow to WindowsDesktop in couple weeks. |
Oh wow that would be bad. Is there a tracking issue for that? |
It seems that winforms flows through wpf - last update was exactly one week ago: dotnet/windowsdesktop#4260 |
Added two more patches - for |
Sigh... few more of the same in
|
Updated the PR with |
One instance in
|
Pushed a patch for |
Messed up the patch - will redo. |
Hmm, interesting - another failure in nuget.client - peeling the onion... |
Pushed the fix. In total there are 2 CA2022 errors in nuget.client:
|
@NikolaMilosavljevic do you plan to send PRs into the five repositories so that we can remove the patches? I think we should do that. |
I could only do PRs with the same exact changes. The goal was to let repos implement a proper fix, instead of temporarily disable the warning/error. |
I fear that repo owners won't see or get to those issues until they are actually blocked by them (when they upgrade to a recent SDK). That would probably mean having the patches around for two months which is undesirable given that we don't want to rely on patches anymore. I'm not saying that you should do the work, I just wonder how we can get rid of the patches asap. |
Not a problem to create PRs, as I already have all changes in their repos locally - used to create the patches. Will do. |
Rebootstrap with latest build assets:
dotnet-installer: https://dev.azure.com/dnceng/internal/_build/results?buildId=2417808&view=results
dotnet-source-build: https://dev.azure.com/dnceng/internal/_build/results?buildId=2417860&view=results