-
Notifications
You must be signed in to change notification settings - Fork 564
[ci] Rename job names #7186
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
[ci] Rename job names #7186
Conversation
TODO: Rationale
aeaf74e to
f41efa5
Compare
|
|
||
| - stage: smoke_tests | ||
| displayName: Smoke Tests | ||
| displayName: macOS > Smoke Tests |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In order to reduce the verbosity in the GitHub checks that get reported back to the repo, maybe we should keep the stage names mostly unchanged and as simple as possible, while making job names more verbose.
The rename of the Smoke Tests stage to macOS > Smoke Tests is a bit odd, as the smoke test stage contains a job that runs on windows. Unless part of the intent behind the rename was to include stage dependencies in the name?
I would suggest something like this instead (leaving stage display names mostly unchanged):
Stage: Smoke Tests
Job: macOS > Tests > APKs Classic
Resulting GitHub status: Xamarin.Android-PR (Smoke Tests macOS > Tests > Apks Classic
We could also continue to use macOS, Windows, and Linux as stage names for the earlier build stages.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've reverted the - stage > displayName changes, so the historical stage names should be used once more.
I also quoted displayName values which contain #, as the "alt/hover text" for those entries were rendered as … \# …, which was not the intent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works for me, I think we may still end up with some "clunky" names but that's a fair trade off for better traceability.
| jobs: | ||
| - job: ${{ parameters.job_name }} | ||
| displayName: MSBuild With Emulator - macOS-${{ parameters.node_id }} - ${{ parameters.job_suffix }} | ||
| displayName: macOS > Tests > MSBuild+Emulator ${{ parameters.job_suffix }} \#${{ parameters.node_id }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤣 , the \ appears in the "alt/hover text" in AzDO.
I'll need to try quoting the line to allow # in there.
Certain tools such as [Component Governance][0] only use the Pipeline
name -- as defined somewhere in Azure DevOps -- and the `displayName`
property on the [`job` definition][1]. The `displayName` property on
the containing [`stage`][2] is *not* displayed.
This can result in "wonderful" alerts which state that the affected
pipeline is e.g. "Xamarin.Android (macOS)", which isn't particularly
helpful when there are *three* jobs with a `displayName` of `macOS`:
* `designer_integration_mac`
* `mac_bcl_tests`
* `mac_build_create_installers`
Fully understanding these alerts is irksome.
Improve this situation by introducing "redundancy" into the job
`displayName` values, and updating them to follow a pattern:
1. Host Platform
2. Category
3. (Optional) Description
Each part is separated from the others by a ` > `.
Examples:
* Replace `Mac Build` with `macOS > Build`.
* For the previous `macOS` displayName:
* The `designer_integration_mac` job is `macOS > Tests > Designer Integration`
* The `mac_bcl_tests` job is `macOS > Tests > BCL (Emulator)`
* The `mac_build_create_installers` job is `macOS > Create Installers`
* Replace `Build and Smoke Test` with `Windows > Build & Smoke Test`
[0]: https://devdiv.visualstudio.com/DevDiv/_componentGovernance/112013?_a=alerts&typeId=6317076&alerts-view-option=active
[1]: https://docs.microsoft.com/en-us/azure/devops/pipelines/yaml-schema/jobs-job?view=azure-pipelines
[2]: https://docs.microsoft.com/en-us/azure/devops/pipelines/yaml-schema/stages-stage?view=azure-pipelines
|
Just looked at the GitHub "status checks" section of this page, which does include the stage displayName. Consequently, I see values such as:
It's…kinda funny? There's no appeasing all the tooling, is there? |
Certain tools such as Component Governance only use the Pipeline
name -- as defined somewhere in Azure DevOps -- and the
displayNameproperty on the
jobdefinition. ThedisplayNameproperty onthe containing
stageis not displayed.This can result in "wonderful" alerts which state that the affected
pipeline is e.g. "Xamarin.Android (macOS)", which isn't particularly
helpful when there are three jobs with a
displayNameofmacOS:designer_integration_macmac_bcl_testsmac_build_create_installersFully understanding these alerts is irksome.
Improve this situation by introducing "redundancy" into the job
displayNamevalues, and updating them to follow a pattern:Each part is separated from the others by a
>.Examples:
Mac BuildwithmacOS > Build.macOSdisplayName:designer_integration_macjob ismacOS > Tests > Designer Integrationmac_bcl_testsjob ismacOS > Tests > BCL (Emulator)mac_build_create_installersjob ismacOS > Create InstallersBuild and Smoke TestwithWindows > Build & Smoke Test