Skip to content
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

[PERF] all build jobs used for performance testing are now possible to run inividually #112902

Merged
merged 1 commit into from
Feb 28, 2025

Conversation

e-kharion
Copy link
Contributor

For perfBisect we need to have a possibility to build specific builds on demand.

This PR should not change the behavior by default, it only adds possibility to build only selected configurations.

@e-kharion e-kharion self-assigned this Feb 25, 2025
@dotnet-issue-labeler dotnet-issue-labeler bot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Feb 25, 2025
@e-kharion e-kharion added area-Infrastructure perf-pipeline Issues with dotnet-runtime-perf, or runtime-wasm-perf pipelines and removed needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels Feb 25, 2025
Copy link
Contributor

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

@e-kharion e-kharion closed this Feb 25, 2025
@e-kharion e-kharion reopened this Feb 25, 2025
Comment on lines 116 to 117
- ${{ if containsValue(parameters.jobsAndPlatforms, 'monoPacks') }}:
# build mono runtime packs
- template: /eng/pipelines/common/platform-matrix.yml
parameters:
jobTemplate: /eng/pipelines/common/global-build-job.yml
buildConfig: release
runtimeFlavor: mono
platforms:
- android_arm64
jobParameters:
buildArgs: -s mono+libs+host+packs -c $(_BuildConfig)
nameSuffix: Mono_Packs
isOfficialBuild: false
postBuildSteps:
- template: /eng/pipelines/common/upload-intermediate-artifacts-step.yml
parameters:
name: MonoRuntimePacks
isOfficialBuild: false
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not related to this PR as it is just a copy from the old code, but why do we build mono runtime packs with android_arm64 platform?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also do not know. I assume they were getting used at some time. I suppose that is no longer the case?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The mono runtime packs are used in the building of the perfBDN app. As to why android_arm64 over something like windows_arm64, I don't recall anything specific. I think it was to ensure it was labeled android in the pipeline view for easier picking out, but I don't think there is a requirement for android_arm64.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, I took another look, the other reason that android_arm64 was chosen is that influences the arch and os that the build.sh command passes in. So by choosing android_arm64, the android packages and what not are built targeting the android OS.

…ndividually

added possibility to configure maui framework to use
perf-build-jobs splitted to multiple templates
perf-arm64-builds moved to a different yml and yml files reorganized
@e-kharion e-kharion reopened this Feb 26, 2025
@DrewScoggins
Copy link
Member

Do we also plan to add these configs as selectable values when starting a manual build so that we can limit what we are building for testing scenarios?

@e-kharion
Copy link
Contributor Author

Do we also plan to add these configs as selectable values when starting a manual build so that we can limit what we are building for testing scenarios?

It should be easy if there is buy-in for it. I'd add it, however, in a separate PR, so this one can be merged to unblock follow-up work.

@e-kharion e-kharion merged commit 9022f3a into dotnet:main Feb 28, 2025
23 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-Infrastructure perf-pipeline Issues with dotnet-runtime-perf, or runtime-wasm-perf pipelines
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

5 participants