metamask / action-create-release-pr Goto Github PK

We should add ShellCheck (a linter for shell scripts) to CI, to improve the quality of our scripts and prevent mistakes and dangerous patterns.

We use it on the extension with this CircleCI job. We should be able to find an equivalent GitHub action, or write one if necessary.

Currently, this action makes a set of changes that are needed to create a new release and groups those changes into a branch/PR. For convenience we call these changes a "release candidate", and in order to create a release candidate, two things must happen:

1. The root package should be bumped along with any packages that have changed since the previous release.
2. The changelog should be updated with the commits that will be included in the new release.

We want to change the process of releasing a monorepo such that:

1. When bumping packages, versions are no longer synchronized with the root package.
2. Each package gets its own changelog, so each package's changelog should be updated accordingly.

To accommodate this, we want to turn this action into a command-line tool. This tool should work for both monorepos and polyrepos. This likely means we need to create a new repo to hold this tool, but I am creating this issue here for convenience.

Monorepos

For a particular monorepo, when the developer runs this tool, it should list all packages matched by the root package's workspaces property that have been updated since the last tag of the monorepo. This prompt should allow the developer to select which packages should be bumped and how (major, minor, patch, exact version).

For each package the developer has selected, the tool should then look at the commits made since the last published release of the package that change any part of the package and add those commits under a new section within the package's changelog that is headered by the new version selected for that package.

Polyrepos

The command-line tool should also work for polyrepos as well. In this case, there is no need to list multiple packages; all that is required is to ask for how the root package should be bumped (major, minor, patch, exact version).

The tool should then look at the commits made since the last published release of the package and add those commits under a new section within the package's changelog that is headered by the new version selected for that package.

If the release branch already exists, the action will fail with an error message that doesn't make it obvious why it failed. We should plainly state that the release branch already exists, and that it should be deleted to run the action.

We should follow the example of MetaMask/action-monorepo-release-pr.

on:
    workflow_dispatch:
        inputs:
            release-type:
                description: 'A SemVer version diff, i.e. major, minor, patch, prerelease etc. Mutually exclusive with "release-version".'
                required: false
            release-version:
                description: 'A specific version to bump to. Mutually exclusive with "release-type".'
                required: false

Using this on private personal repos errors:

pull request create failed: GraphQL error: Draft pull requests are not supported in this repository.

Their docs describe:

Draft pull requests are available in public repositories with GitHub Free for organizations and legacy per-repository billing plans, and in public and private repositories with GitHub Team, GitHub Enterprise Server 2.17+, and GitHub Enterprise Cloud

Source: https://docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests#draft-pull-requests

Ideally this --draft should become optional via an input parameter

It would be helpful to show the changelog in the release PR description, to help the reviewers understand what has changed in the release. We could embed the entire changelog contents for the current release, or we could do something simpler like link the section of the changelog for the current release.

Currently, this action fails if tag validation fails, including if the most recent tag is not a valid SemVer version. We should add a configurable tag ignore list, probably via an action input, maybe using globs.

dist/index.js is a generated file and creates noise in PRs. We should consider hiding this by default.

Currently, this action "synchronizes" package versions in monorepos (i.e., updates the version of all monorepo packages wherever they appear as dependencies in this monorepo), for major releases only. This has often created problems for us, and we should consider making it always synchronize package versions or parameterize the behavior.

We need to keep two things in mind while making this change:

1. The most recent published versions of all packages should be compatible per SemVer
2. Packages should always be internally compatible in the monorepo
   • This is the rub, because if package versions become unsynchronized in the monorepo, yarn setup/ yarn install will install monorepo packages from the registry instead of linking the local versions. IIRC, there's some kind of setting (maybe in .yarnrc?) that forces yarn to always install from the monorepo, but I'm not sure. If that setting exists, we could just document that monorepos that use this action should enable it. Otherwise, we may just have to default to synchronizing versions.

As a convenience, maintainers of popular actions (e.g. actions/checkout) maintain a shorthand major version tag (e.g. v1) that points to the latest major version release. We recommend using this same shorthand for our release automation actions, but the tag has to be updated manually. We should automate the updating of this tag, which ought to be simple enough.

Currently, if a monorepo package is released during a major version bump but hasn't changed, the changelog is by default empty. We should consider adding some kind of default so as to not confuse readers.

Because the author of the pull request is the GitHub Actions bot, the creator of the release pull request can also merge it. This is bad. (I am bad.)

The action initiator is identified by the github.actor context property (see this page) during workflow runs. We could instrument the action to make the action initiator the PR author, but that would require everyone to create and manage Personal Access Tokens. That would be bad.

A better solution, suggested by @Gudahtt, is to somehow identify the action initiator in the release PR itself, and use a second action as a mandatory check that only passes if someone other than the initiator approves the PR.

After some research, I believe that the best way to accomplish this is to use artifacts. Artifacts are specific to repositories, persisted to specified paths between workflow runs, and GitHub provides easy-to-use actions to upload and download them.

This action should, after creating the release PR, upload an artifact identified by some UID (e.g., the PR number), containing the string value of github.actor. We should then create a second action or workflow that downloads this artifact and only succeeds if someone other than the initiator of this action has approved the PR. GitHub deletes artifacts after 90 days by default, so cleanup shouldn't be necessary, but we can optionally delete the artifact in a third workflow when the PR is closed (pull_request, closed).