Skip to content

Merge satori upstream and bring us up to date with main#3250

Open
agocke wants to merge 4 commits intodotnet:feature/satorifrom
agocke:merge-satori-upstream
Open

Merge satori upstream and bring us up to date with main#3250
agocke wants to merge 4 commits intodotnet:feature/satorifrom
agocke:merge-satori-upstream

Conversation

@agocke
Copy link
Member

@agocke agocke commented Mar 16, 2026

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

@MichalStrehovsky
Copy link
Member

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.

@jkotas
Copy link
Member

jkotas commented Mar 16, 2026

The github delta shows changes unrelated to Satori. Is the merge done right?

@jkotas jkotas requested a review from janvorli March 16, 2026 22:34
@agocke
Copy link
Member Author

agocke commented Mar 16, 2026

This also brings us all the way to .NET 10 and part way through .NET 11.

@agocke
Copy link
Member Author

agocke commented Mar 16, 2026

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.

@jkotas
Copy link
Member

jkotas commented Mar 16, 2026

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.

@janvorli
Copy link
Member

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.

@agocke agocke force-pushed the merge-satori-upstream branch from 21ce77b to bf90adb Compare March 17, 2026 20:59
@agocke
Copy link
Member Author

agocke commented Mar 18, 2026

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

@agocke agocke force-pushed the merge-satori-upstream branch from cc37d52 to bdc16e4 Compare March 18, 2026 06:52
@agocke
Copy link
Member Author

agocke commented Mar 18, 2026

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.

@jkotas
Copy link
Member

jkotas commented Mar 18, 2026

@agocke
Copy link
Member Author

agocke commented Mar 18, 2026

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.

@VSadov
Copy link
Member

VSadov commented Mar 18, 2026

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:

  • make the feature/satori branch to match b8e7226 (i.e. common dotnet/Satori point - just before Satori commits)
    I assume a runtimelab branch might have some diffs on its own - due to infra differences and the like, but hopefully mostly outside of \src.

(it could be interesting to know if anything builds or passes tests in this state)

  • apply remaining changes from satori main (merge or cherrypick the extra commits, whatever works...)

  • Then we should be able to take merges from more recent dotnet main.

This way it could be more incremental and no single step should change 3000+ files.

@agocke
Copy link
Member Author

agocke commented Mar 19, 2026

I don't have force push permissions for this branch, but I might be able to elevate.

@agocke agocke force-pushed the merge-satori-upstream branch from bdc16e4 to 497dc8f Compare March 19, 2026 04:12
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@agocke
Copy link
Member Author

agocke commented Mar 19, 2026

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.

@jkotas
Copy link
Member

jkotas commented Mar 19, 2026

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.

@VSadov
Copy link
Member

VSadov commented Mar 19, 2026

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:
(140 commits, 162 files)

dotnet/runtime@main...VSadov:satoriBranch

It looks like something brings over 800+ unrelated commits into the current PR.

@VSadov
Copy link
Member

VSadov commented Mar 19, 2026

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:

image

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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants