Skip to content

Conversation

@jonpryor
Copy link
Contributor

@jonpryor jonpryor commented Jul 20, 2022

Certain tools such as Component Governance only use the Pipeline
name -- as defined somewhere in Azure DevOps -- and the displayName
property on the job definition. The displayName property on
the containing stage 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

@jonpryor jonpryor requested a review from pjcollins as a code owner July 20, 2022 19:24
TODO: Rationale
@jonpryor jonpryor force-pushed the jonp-redundency-in-job-displaynames branch from aeaf74e to f41efa5 Compare July 20, 2022 21:09

- stage: smoke_tests
displayName: Smoke Tests
displayName: macOS > Smoke Tests
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

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 }}
Copy link
Contributor Author

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
@jonpryor
Copy link
Contributor Author

Just looked at the GitHub "status checks" section of this page, which does include the stage displayName. Consequently, I see values such as:

  • Xamarin.Android-PR (Linux Linux > Build)
  • Xamarin.Android-PR (Mac macOS > Build)
  • Xamarin.Android-PR (Windows Windows > Build & Smoke Test)

It's…kinda funny? There's no appeasing all the tooling, is there?

@jonpryor jonpryor merged commit 3781fc1 into dotnet:main Jul 21, 2022
@github-actions github-actions bot locked and limited conversation to collaborators Jan 24, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants