task-release: Request reviews from the authors of released changes

[jtrobles-cdd]

Context

A release or publication pull request gathers the work of several people, and nothing told any of them that their changes were about to reach production. Both release task workflows now request a review from the GitHub user who authored each commit the pull request carries, behind an input that defaults to being on.

Decisions Somebody Should Weigh In On

• The input defaults to true, so every caller starts requesting reviews as soon as this reaches master, including the five that run the production release on a schedule. A VCS repository that does not want it has to pass request_reviews_from_change_authors: false.
• Both workflows open the pull request as a draft, and a review requested on a draft notifies the reviewer straight away rather than when it is marked ready for review, so the authors are notified at creation time rather than when somebody is actually ready for them to look.
• The authors come from repos/{owner}/{repo}/pulls/{number}/commits rather than from gh pr view --json commits. The latter carries Co-authored-by trailers but truncates at 100 commits, which a release routinely exceeds, so the trade is that co-authors are not requested.
• A user who cannot be a reviewer, such as one who has left the organization, produces a warning annotation rather than a failed job, because a release must not fail over a review request. That makes it a silent gap unless somebody reads the annotations.
• In Release and Deploy to Production the new step runs after the checklist comment, so that an unreachable GitHub API costs the review requests rather than the checklist.
• The header comment of each workflow was rewritten rather than extended with the new behaviour, because what it listed was the steps, which the step names already carry. What is there now is what the steps do not say, which for Release and Publish is the precondition that it only works when called from a merged pull_request event, since every value it builds the publication pull request from comes out of github.event.pull_request.

What I Could Not Verify

• Neither workflow can be exercised outside a real release, and this VCS repository has no harness for running one, so the first release of a caller that takes this version is the actual test of it. What that first run has to show is that the step finds the authors at all: the pull request is created with the token of GitHub Actions, and the commit authors it reports are the ones GitHub resolved from email addresses, which is empty for a commit whose author it cannot match to a user.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud