Use the Maestro versions for MicroBenchmarks.csproj

[cincuranet]

Depends on #3174 and #3173.
Fixes #3164.

[SamMonoRT]

cc @radical @kotlarmilos

[lewing]

running darc update-dependencies --channel ".NET 8" or darc update-dependencies --id 186291 on this pr will get you real version numbers for the deps. It will also update the illink versions, is that going to be a problem?

[cincuranet]

@lewing I already rebased on top of #3176, so we're good. Regarding ILLink, let's see.

[DrewScoggins]

It shouldn't be an issue for the real version numbers for our extension assemblies. The Illink dependency update is a bit more interesting. @sbomer

[radical]

@cincuranet are you already running a build on dotnet-runtime-perf for this?

[radical]

/datadisks/disk1/work/B4900A21/w/9E8D08B7/e/src/benchmarks/real-world/ILLink/ILLinkBenchmarks.csproj : error NU1603: Warning As Error: ILLinkBenchmarks depends on Microsoft.NET.ILLink (>= 8.0.0-rc.1.23377.1) but Microsoft.NET.ILLink 8.0.0-rc.1.23377.1 was not found. An approximate best match of Microsoft.NET.ILLink 8.0.100-1.22608.1 was resolved.

[radical]

I have started https://dev.azure.com/dnceng/internal/_build/results?buildId=2230773 for this branch. But this will run only wasm jobs, because for wasm we can run off a fork.

diff --git a/eng/pipelines/coreclr/perf.yml b/eng/pipelines/coreclr/perf.yml
index ae734cbfdaa..b4f3f673964 100644
--- a/eng/pipelines/coreclr/perf.yml
+++ b/eng/pipelines/coreclr/perf.yml
@@ -49,5 +49,8 @@ extends:
             runProfile: 'non-v8'
           ${{ if and(ne(variables['System.TeamProject'], 'public'), notin(variables['Build.Reason'], 'Schedule')) }}:
             runProfile: 'v8'
+          perfForkToUse:
+            url: https://github.com/cincuranet/performance
+            branch: maestro-version

-      - template: /eng/pipelines/coreclr/perf-non-wasm-jobs.yml
+      #- template: /eng/pipelines/coreclr/perf-non-wasm-jobs.yml

[radical]

I have started dev.azure.com/dnceng/internal/_build/results?buildId=2230773 for this branch. But this will run only wasm jobs, because for wasm we can run off a fork.

All the wasm jobs just timed out waiting for helix agents, after 5+ hours. @LoopedBard3 have the machines taken out for testing been added back? I have been hitting this issue for quite some time now.

[cincuranet]

@radical We have currently migration from Ubuntu 18.04 to 22.04 happening and that queue is temporarily operating with limited capacity.

[radical]

@radical We have currently migration from Ubuntu 18.04 to 22.04 happening and that queue is temporarily operating with limited capacity.

Is the only way to test this is to merge it then?

[SamMonoRT]

@sblom @cincuranet - If merging is the only way we can test this, I would suggest merge this asap. Runs seem completely broken at this time and we need to give it a shot.

[cincuranet]

@radical It will end up in the same queue.

[cincuranet]

If somebody gives me approval, I'll merge ASAP.

[radical]

@radical It will end up in the same queue.

But dotnet-runtime-perf does seem to get some preference? I have tried this a few times recently, where I can't get any agents when doing a manual pipeline run, but it works fine with dotnet-runtime-perf. Maybe this was a coincidence, I don't know.

[cincuranet]

I'm not aware of any preference, but maybe there's some logic there.