Release - #118
Merged
Merged
Release#118
Conversation
Bumps [actions/setup-node](https://github.com/actions/setup-node) from 6.4.0 to 7.0.0. - [Release notes](https://github.com/actions/setup-node/releases) - [Commits](actions/setup-node@v6.4.0...v7.0.0) --- updated-dependencies: - dependency-name: actions/setup-node dependency-version: 7.0.0 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
…s/setup-node-7.0.0 chore(deps): Bump actions/setup-node from 6.4.0 to 7.0.0
- 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. - It is an input so that a VCS repository whose releases do not warrant it can turn it off, and it defaults to being on, because the common case is wanting the authors to know. - The authors are read from the GitHub API rather than from the Git history, because only GitHub can resolve the email address of a commit to a GitHub user. The commits are paginated, as a release easily exceeds the size of a single page. - A review is requested from one user at a time, because GitHub rejects the whole request when a single one of the users cannot be a reviewer, for instance because they have left the organization, and a release must not fail over that. - In 'Release and Deploy to Production' the step runs last, so that an unreachable GitHub API cannot cost the release and deployment checklist, which is worth more than the review requests. - The header comment of each workflow no longer lists the steps, which the step names already carry, and says instead what the pull request it opens is for, which none of them does. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…ws-1d171f task-release: Request reviews from the authors of released changes
- A release runs on a schedule in most of the callers, and its outcome was only visible by opening the log of the run. What somebody has to act on is the pull request it opens, so the summary carries its URL first, right under the heading. - A run that finds nothing to release writes a summary of its own, because that is the outcome of most scheduled runs, and an empty summary does not distinguish it from a run that failed early. - The number of changes is now an output of the step that counts them, because the summary states it and the step that opens the pull request is the one that writes it. - The review step records which users were requested and which of them GitHub rejected, because a rejection is otherwise only a warning annotation that nobody reads. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
task-release: Add a job summary to the release workflows
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Changes