Pin the pull request dashboard stable channel to v0.5.0

.github/scripts/pull-request-dashboard/RATIONALE.md

@@ -63,10 +63,11 @@ the implementation understandable and operationally cheap.
   branch. The version that each repository runs is then visible in the workflow
   file, a rollback is a revert, and the reference stays hash pinned the way
   every other action reference in this repository is.
-- Until the first promotion the stable jobs call the local workflow, so both
-  channels run the same code. A cross-repository reference cannot be introduced
-  in the same change that adds the `code_ref` input, because the commit it would
-  have to pin does not exist yet.
+- A rollback stops a bad change rather than restoring delivery. Downgraded code
+  reads newer delivery state as empty, so delivering from it would repeat
+  reminders and re-review requests already sent; the delivery version check
+  makes it skip delivery instead. Rolling forward is the way out, and a paused
+  dashboard is the cheaper failure.
 
 ## Workflow Concurrency
 

.github/workflows/pull-request-dashboard.yml

@@ -188,9 +188,7 @@ jobs:
   # on the canary repositories.
   #
   # `uses` cannot take an expression, so each entry path has one job per
-  # channel. The stable jobs below still call the local workflow, which means
-  # both channels currently run the same code. Promoting for the first time, and
-  # every time after, means cutting a release and opening a pull request that
+  # channel. Promoting means cutting a release and opening a pull request that
   # points every stable job at that release:
   #
   #   uses: open-telemetry/shared-workflows/.github/workflows/pull-request-dashboard-repo.yml@<sha> # vX.Y.Z
@@ -230,9 +228,10 @@ jobs:
       fail-fast: false
       max-parallel: 3
       matrix: ${{ fromJSON(needs.resolve-targets.outputs.stable_matrix) }}
-    uses: ./.github/workflows/pull-request-dashboard-repo.yml
+    uses: open-telemetry/shared-workflows/.github/workflows/pull-request-dashboard-repo.yml@94425809b433630371efafff2067f2c5b19f3fc2 # v0.5.0
     with:
       repository: ${{ matrix.name }}
+      code_ref: 94425809b433630371efafff2067f2c5b19f3fc2 # v0.5.0
     secrets:
       PR_DASHBOARD_PRIVATE_KEY: ${{ secrets.PR_DASHBOARD_PRIVATE_KEY }}
       SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}
@@ -268,10 +267,11 @@ jobs:
     permissions:
       contents: write
       copilot-requests: write
-    uses: ./.github/workflows/pull-request-dashboard-repo.yml
+    uses: open-telemetry/shared-workflows/.github/workflows/pull-request-dashboard-repo.yml@94425809b433630371efafff2067f2c5b19f3fc2 # v0.5.0
     with:
       repository: ${{ inputs.repository }}
       pr_number: ${{ inputs.pr_number }}
+      code_ref: 94425809b433630371efafff2067f2c5b19f3fc2 # v0.5.0
     secrets:
       PR_DASHBOARD_PRIVATE_KEY: ${{ secrets.PR_DASHBOARD_PRIVATE_KEY }}
       SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}
@@ -302,10 +302,11 @@ jobs:
     permissions:
       contents: write
       copilot-requests: write
-    uses: ./.github/workflows/pull-request-dashboard-repo.yml
+    uses: open-telemetry/shared-workflows/.github/workflows/pull-request-dashboard-repo.yml@94425809b433630371efafff2067f2c5b19f3fc2 # v0.5.0
     with:
       repository: ${{ inputs.repository }}
       pr_number: ${{ needs.resolve-head-sha.outputs.pr_number }}
+      code_ref: 94425809b433630371efafff2067f2c5b19f3fc2 # v0.5.0
     secrets:
       PR_DASHBOARD_PRIVATE_KEY: ${{ secrets.PR_DASHBOARD_PRIVATE_KEY }}
       SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

pull-request-dashboard/README.md

@@ -261,9 +261,15 @@ its settings, takes effect on the next run in both channels.
    as a comment the way actions are pinned elsewhere in this repository.
    `test_rollout.py` fails if the two disagree.
 
-Rolling back before a promotion means not promoting; after a promotion it means
-reverting the bump. Until the first promotion the stable jobs call the workflow
-at the triggering commit, so both channels run the same code.
+### Rolling back
+
+Revert the bump to an earlier release commit. If the reverted change bumped no
+delivery version, the stable channel resumes normally. If it did, those
+repositories stop delivering rather than repeat reminders they can no longer see
+as sent, so recovery is to roll forward with a fix. Canary repositories are
+unaffected either way, since they never run pinned code.
+
+### Changing the workflow
 
 Running two versions at once adds two rules for changes to this workflow: