Merge satori upstream and bring us up to date with main#3250
Merge satori upstream and bring us up to date with main#3250agocke wants to merge 4 commits intodotnet:feature/satorifrom
Conversation
|
We should also delete CODEOWNERS to avoid spurious pings. https://github.com/dotnet/runtimelab/blob/docs/CreateAnExperiment.md lists this and a couple other things that may be needed. |
|
The github delta shows changes unrelated to Satori. Is the merge done right? |
|
This also brings us all the way to .NET 10 and part way through .NET 11. |
|
I could try to reset this branch to main first in a separate PR, but it's not clear to me if that's more readable -- I would still need to resolve conflicts with the exsting branch, but that's basically what Vlad's done here. |
|
https://github.com/dotnet/runtime/compare/main...agocke:runtime:merge-satori-upstream?expand=1 shows the delta between this branch and dotnet/runtime main. There seems to be a lot of changes unrelated to satori (click on "File changed" to see them). For example, many of the .csproj files deleted in #121078 are being reintroduced. I do not have strong opinions on how to fix that. No need to reset the branch. I think it is fine to push more commits to undo the undesirable deltas. |
|
I have looked at the diff through the link @jkotas shared. It seems there are even some completely wrong merges, at least the one in src/coreclr/debug/di/process.cpp where the change added a copy of the same, just little modified code instead of updating the existing part. |
21ce77b to
bf90adb
Compare
|
I'm going to re-run the merge -- my goal here will to be to bring over the new branch contents as cleanly as possible |
cc37d52 to
bdc16e4
Compare
|
OK, I think I got git to basically do the merge itself and prefer vlad's changes, so this merge shouldn't have manual modifications by copilot. Obviously would prefer a second look by someone else. |
|
I still see a number of unrelated deltas in https://github.com/dotnet/runtime/compare/main...agocke:runtime:merge-satori-upstream?expand=1 |
|
Hm. OK, I need to dig deeper into some of these commits. I think I would expect a gap between main and this branch because @VSadov's branch is still a bit behind. But some of these commits are strange, I would definitely expect them to appear. |
|
3000+ files changes does not seem right. Satori main has been rebased onto b8e7226 , which is dotnet main from around 02/10/26 Perhaps a better course of action would be:
(it could be interesting to know if anything builds or passes tests in this state)
This way it could be more incremental and no single step should change 3000+ files. |
|
I don't have force push permissions for this branch, but I might be able to elevate. |
bdc16e4 to
497dc8f
Compare
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
OK, I've reset the branch and now this PR just brings back the commits needed for runtimelab specifically. I think this is the last time we should do this -- all future changes can come through PRs. |
|
dotnet/runtime@main...agocke:runtime:merge-satori-upstream still shows a bunch of unrelated changes. It is a problem with merges done in https://github.com/VSadov/Satori/ that will likely need to be cleaned up at some point. |
I did not do merges in Satori. "Rebasing" was always a hard sync with upstream + re-adding commits on top. The diff with dotnet/main looks very clean: dotnet/runtime@main...VSadov:satoriBranch It looks like something brings over 800+ unrelated commits into the current PR. |
|
Actually it looks like there are two "merge-satori-upstream" branches this one has unexpected commits from various servicing branches - dotnet/runtime@main...agocke:runtime:merge-satori-upstream , but it is not what we are merging here. It looks correct to me: The diff with dotnet/main is the Satori/main top commits, which are already in the runtimelab/feature/satori + 3 new commits specific to runtimelabs:
|
Two fixes for build 1342484 failures: 1. Checked test jobs (linux-x64, windows-x64): The build uses '-c debug -rc Checked' so libs are at Debug config, but test-variables.yml defaults LibrariesConfiguration to the buildConfigUpper (Checked). Pass liveLibrariesBuildConfig: Debug to match the actual libs build configuration. 2. Release Helix job (linux-x64): global-build-job.yml passes lowercase 'release' to helix.yml which sets /p:Configuration=release. The build step uses $(_BuildConfig)=Release (proper case). On Linux the testhost path is case-sensitive, so the correlation payload zip is never found. Override via extraHelixArguments with the properly cased $(_BuildConfig). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Brings in the latest commit from vsadov/satori, which also brings us up to date with .NET 10 and partway through .NET 11 (main)