Use the Maestro versions for MicroBenchmarks.csproj#3175
Use the Maestro versions for MicroBenchmarks.csproj#3175cincuranet merged 1 commit intodotnet:mainfrom cincuranet:maestro-version
Conversation
|
running |
|
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 |
|
@cincuranet are you already running a build on dotnet-runtime-perf for this? |
|
|
|
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 |
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. |
|
@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? |
|
@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. |
|
@radical It will end up in the same queue. |
|
If somebody gives me approval, I'll merge ASAP. |
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. |
|
I'm not aware of any preference, but maybe there's some logic there. |
Depends on #3174 and #3173.
Fixes #3164.