diff --git a/.github/scripts/pull-request-dashboard/RATIONALE.md b/.github/scripts/pull-request-dashboard/RATIONALE.md index ca79dc5fa79..cc18dfb4e47 100644 --- a/.github/scripts/pull-request-dashboard/RATIONALE.md +++ b/.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 diff --git a/.github/workflows/pull-request-dashboard.yml b/.github/workflows/pull-request-dashboard.yml index 2288b2dc5b0..2ae835d1772 100644 --- a/.github/workflows/pull-request-dashboard.yml +++ b/.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@ # 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 }} diff --git a/pull-request-dashboard/README.md b/pull-request-dashboard/README.md index d5c4dd71e10..b5221f3d597 100644 --- a/pull-request-dashboard/README.md +++ b/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: