- -```html - -
This checklist is based on the Release Checklist Template. If you need a checklist for a new gutenberg-mobile release, please copy from that template.
- - - -+mobilegutenberg
- - - -o Visit all open gutenberg-mobile PRs that are assigned to X.XX.X milestone and leave a comment with a message similar to the following:
- - - --Hey [author]. We will cut the X.XX.X release on [date]. I plan to circle back and bump this PR to the next milestone then, but please let me know if you'd rather us work to include this PR in X.XX.X. Thanks!
o Verify that gutenberg-mobile/RNTAztecView.podspec and gutenberg-mobile/gutenberg/packages/react-native-aztec/RNTAztecView.podspec refer to the same WordPress-Aztec-iOS version and are pointing to a stable, tagged release (e.g. 1.14.1). If they are not, we may need to create a new Aztec release.
o Clone the release scripts or pull the latest version if you have already cloned it.
- - -o Review the release script instructions. In your clone of the release scripts, run the script via: ./release_automation.sh. This creates the gutenberg and gutenberg-mobile release PRs as well as WPAndroid and WPiOS integration PRs.
o If this is a scheduled release (e.g. X.XX.0) and not a beta/hot fix (e.g. X.XX.2), post a message similar to the following to the #mobile-gutenberg and #mobile-gutenberg-platform Slack channels:
-⚠️ The gutenberg-mobile X.XX.X release branches are now cut. Please do not merge any Gutenberg-related changes into the WPiOS or WPAndroid
trunkbranches until after the main apps cut their own releases next week. If you'd like to merge changes now, merge them into thegutenberg/after_X.XX.Xbranches.
o In both RELEASE-NOTES.txt and gutenberg/packages/react-native-editor/CHANGELOG.md, replace Unreleased section with the release version and create a new Unreleased section.
o Review and update RELEASE-NOTES.txt file on both WPAndroid and WPiOS PRs so it includes all user-facing changes introduced in the release. Keep in mind that some changes can be specific to a single platform, so they should only be added to the release notes of the platform that affects (e.g. a change that only affects Android should only be included in WPAndroid release notes).
o Verify the WPAndroid and WPiOS PR builds succeed. For WPAndroid, if the PR CI tasks include a 403 error related to an inability to resolve the react-native-bridge dependency, you must wait for the Build Android RN Bridge & Publish to S3 task to succeed in gutenberg-mobile and then restart the WPAndroid CI tasks. Similarly, for iOS, you must wait for the Build iOS RN XCFramework & Publish to S3 task to succeed.
o Once the installable builds are ready, perform a quick smoke test of the editor on both iOS and Android to verify it launches without crashing. We will perform additional testing after the main apps cut their releases.
- - - -o Fill in the missing parts of the gutenberg-mobile PR description. When filling in the "Changes" section, link to the most descriptive GitHub issue for any given change and consider adding a short description. Testers rely on this section to gather more details about changes in a release.
- - - -o Mark all 4 PRs ready for review and request review from the team.
- - - -⚠️ In some release cases (like beta fixes), it's likely that the PRs could have conflicts with trunk. In this case, do not resolve merge conflicts by merging with trunk as this will introduce new and unexpected changes to the release. Instead, leave the conflicts until the release is integrated into the main apps, and then resolve the conflicts when merging the PRs back to trunk. Optionally, a second clone of the release branch can be created to verify the CI checks.
o If this is a release for inclusion in the frozen WPiOS and WPAndroid release branches (i.e. this is a beta/hot fix, e.g. X.XX.2), ping the directly responsible individual handing the release of each platform of the main apps.
- - - -ℹ️ If gutenberg-mobile/RNTAztecView.podspec and gutenberg-mobile/gutenberg/packages/react-native-aztec/RNTAztecView.podspec refer to a commit SHA instead of a stable release (e.g. 1.14.1) or refer to different versions, the steps in this section may need to be completed.
o Verify all Aztec PRs attached to the "Next Release" milestone or PRs with changes required for this Gutenberg release have been merged before next steps.
- - - -o Open a PR on Aztec repo to update the CHANGELOG.md and README.md files with the new version name.
o Create a new release and name it with the tag name from step 1. For Aztec-iOS, follow this process. For Aztec-Android, releases are created via the GitHub releases page by hitting the “Draft new release” button, put the tag name to be created in the tag version field and release title field, and also add the changelog to the release description. The binary assets (.zip, tar.gz files) are attached automatically after hitting “Publish release”.
- - - -o Update Aztec version references within gutenberg-mobile/RNTAztecView.podspec and gutenberg-mobile/gutenberg/packages/react-native-aztec/RNTAztecView.podspec to the new WordPress-Aztec-iOS version.
ℹ️ If additional changes (e.g. bug fixes) were merged into the gutenberg-mobile release/X.XX.X or in gutenberg rnmobile/release-X.XX.X branches, the steps in this section need to be completed.
o After a merge happened in gutenberg-mobile release/X.XX.X or in gutenberg rnmobile/release-X.XX.X, ensure the gutenberg submodule points to the correct hash and the rnmobile/release-X.XX.X in the gutenberg repo branch has been updated.
o If there were changes in gutenberg repo, make sure to cherry-pick the changes that landed in the trunk branch back to the release branch and don't forget to run npm run bundle in gutenberg-mobile again if necessary.
o Add the new change to the "Extra PRs that Landed After the Release Was Cut" section of the gutenberg-mobile PR description.
- - - -o Verify the gutenberg ref within the gutenberg-mobile release branch is pointed to the latest commit in the gutenberg release branch.
o Create and push a rnmobile/X.XX.X git tag for the head of gutenberg release branch.
o Ensure that the bundle files are updated to include any changes to the release branch by running npm run bundle in gutenberg-mobile release branch and committing any changes.
o Create a new gutenberg-mobile GitHub Release. Include a list of changes in the Release description. Ensure the checkmark "Set as the latest release" is checked, and publish the release with the "Publish release" button.
- - - -o Wait until all CI jobs for the published tag finish and succeed.
- - - -o Navigate to the Buildkite job that built the JS bundles (Build JS Bundles) for the published tag. Open the job and navigate to the "Artifacts" tab. Locate the composed source maps (they have file name bundle/{platform}/App.composed.js.map) and download them.
o Navigate and edit the GitHub release. Attach the composed source maps to the release (you can drag and drop the files in the "Attach binaries" drop area). Once they are uploaded, update the artifact's name following this format:
- - - -bundle/android/App.composed.js.mapandroid-App.js.mapbundle/ios/App.composed.js.mapios-App.js.mapo In WPiOS, update the reference to point to the tag of the Release created in the previous task.
- - - -o In WPAndroid, update the gutenbergMobileVersion in build.gradle to point to the tag of the Release used in the previous task.
o Main apps PRs should be ready to merge to their trunk branches now. Merge them or get them merged.
o Once everything is merged, send a heads up to our friends in the #apps-infrastructure Slack channel. If this is a "regular" release for the WPiOS and WPAndroid `trunk` branches (i.e. this isn't a beta/hot fix, e.g. X.XX.2), the message will look similar to the following:
- - - -Hey team. I wanted to let you know that the mobile Gutenberg team has finished integrating the X.XX.X Gutenberg release into the WPiOS and WPAndroid `trunk` branches. The integration is ready for the next release cut/build creation when you are available. Please let me know if you have any questions. Thanks!
o If the release is a beta/hot fix (e.g. X.XX.2), be sure to directly mention the relevant Excellence Wranglers for the release and modify the following template, similar to the following:
- - - --Hey team. I wanted to let you know that the mobile Gutenberg team has finished integrating the X.XX.X Gutenberg release into the WPiOS and WPAndroid `release/XX.X` branches, ready for a new beta when you are available. Please let me know if you have any questions. Thanks!
o Close the Gutenberg Mobile milestone that corresponds to this release.
- - - -o Resolve any conflicts with trunk and merge the gutenberg PR.
o Update the gutenberg reference on the gutenberg-mobile release branch to point to the Gutenberg PR merge commit
- - - -o Merge the gutenberg-mobile PR to trunk. Use "Create a merge commit" option when merging to avoid losing any commit history from the release branch.
⚠️ This section may only be completed after the main apps cut their own release branches.
- - - -o Update the gutenberg/after_X.XX.X branches and open a PR against trunk. If the branches are empty we’ll just delete them. The PR can actually get created as soon as something gets merged to the gutenberg/after_X.XX.X branches. Merge the gutenberg/after_X.XX.X PR(s) only AFTER the main apps have cut their release branches.
ℹ️ Use the main WP apps to complete each the tasks below for both iOS and Android, and post the results of each test group/suite as a comment on the gutenberg-mobile release PR (merged at this point in time).
- - - -o Test the new changes that are included in the release PR.
- - - -o Complete the general writing flow test cases.
- - - -o Complete the Unsupported Block Editor test cases.
- - - -o Complete the functionality tests scheduled for Android.
- - - -o Complete the functionality tests scheduled for iOS.
- - - -For the remainder of the main app release period, monitor main app release P2 posts for issues found.
- - - -o Update the Release Incident Spreadsheet with any fixes that occurred after the release branches were cut.
- - - -o If this is a scheduled release (e.g. X.XX.0), message the next release wrangler in the #mobile-gutenberg-platform Slack channel providing them with a tentative schedule for the next release. This will help ensure a smooth hand off and sets expectations for when they should begin their work.
o Celebrate! 🎉
- ``` - - - -[Add reason for releasing the fix HERE]
- +go run main.go render checklist -v X.XX.X --message "This hotfix addresses ISSUE_OR_CRASH in ORIGINAL_VERSION. See P2_PR_SLACK_ETC_LINK_OR_LINKS for the rationale behind the decision to make it." ``` # Different types of releases @@ -332,7 +26,7 @@ It's best practice to use the automation script (mentioned in the release templa ### When -Whenever a build is needed for testing (usually a few days prior to a Regular release) +Whenever a build is needed for testing (usually a few days prior to a Regular release). ### Branches @@ -393,8 +87,7 @@ At the same time there could also be a regular release going on for example for ### Automation script differences -1. Before running the script switch to the relevant branch to cut from in gutenberg-mobile repo. -1. Run [release_automation.sh](./release_automation.sh) as usual. +1. Run the CLI tool as normal 1. When asked by the script enter the relevant branch names to cut from (to target) in other repos. 1. If a commit that is fixing the issue is already merged to gutenberg, when asked by the script enter the commit hash to be cherry-picked. @@ -425,11 +118,11 @@ At the same time there could also be a regular release, a betafix or even anothe 1. If necessary create new patch version branches `release/X.Y.1` in WPiOS and WPAndroid. -Rest should be same the as Betafix +The rest should be same the as Betafix. ### Release checklist template differences 1. Include `Hotfix` in the heading 1. After the fix is merged and if there is an ongoing regular release, betafix or hotfix then the changes should be brought back to those branches as well. -Rest should be same the as Betafix +The rest should be same the as Betafix. \ No newline at end of file diff --git a/gbm-cli/README.md b/gbm-cli/README.md index d41e440..947f0ae 100644 --- a/gbm-cli/README.md +++ b/gbm-cli/README.md @@ -7,26 +7,63 @@ The current features include: - Command to generate the release checklist - Commands to wrangle Gutenberg Mobile releases +## Installing +Check the latest release in this repository for the binary builds. Currently we only build for MacOS arm64 (apple silicon). The script has only been tested on apple silicon but build of other platforms should work as expected. See the official [go build](https://go.dev/ref/mod#go-install) documentation for alternative builds. + +If using apple silicon, download the `gbm-cli` binary from the [latest release(https://github.com/wordpress-mobile/release-toolkit-gutenberg-mobile/releases) +Place the executable in your PATH and reload your shell. Try + +``` +$ gbm-cli --version +``` + +To verify installation. + +If `go` (above version `1.21`) is installed you can also use: + +``` +go install github.com/wordpress-mobile/release-toolkit-gutenberg-mobile/gbm-cli@latest +``` + +This will build and install the executable in the `GOPATH` on your machine. +Note: Verify that `GOPATH` is set before using this method. If it's not set run `export GOPATH=$HOME/go` before calling `go install` + +## Authentication + +The tool uses the same Github authentication as [`gh`](https://cli.github.com/). If `gh` is installed and authorized there is no need to do anything else. + +Otherwise follow these steps: + +1. Create a [personal access token](https://github.blog/2013-05-16-personal-api-tokens/) +2. Export the token under the environment variable `GH_TOKEN` + ## Development Environment -1. Download and install the [Go package](https://go.dev/doc/install). -2. While not required, it is higly recommended to develop with [VSCode](https://code.visualstudio.com/) and install the [Go VSCode](https://marketplace.visualstudio.com/items?itemName=golang.go) extension. +1. Download and install the [Go package](https://go.dev/doc/install). Check `go.mod` for the current version of go required (Note: anything below `v1.21` will not work) +2. While not required, it is highly recommended to develop with [VSCode](https://code.visualstudio.com/) and install the [Go VSCode](https://marketplace.visualstudio.com/items?itemName=golang.go) extension. ## Releasing -For detailed instructions on running a release, visit [Releasing.md](https://github.com/wordpress-mobile/release-toolkit-gutenberg-mobile/blob/cli/update-checklist/cli/Releasing.md). + +Check the [Releasing](../Releasing.md) doc for more information on creating Gutenberg Mobile releases. Use the following for creating new releases of the CLI tool + +When ready to push updates to a new `gbm-cli` version make sure to: +- Increment the version in `./cmd/root.go` +- Merge the PR with the version bump +- Create a new Github Release with the updated version. +- Locally checkout the release tag +- Create a `./bin` directory if you don't have one already +- Run `go build -o ./bin/gbm-cli` +- Add `./bin/gbm-cli` as an artifact to the Github release. ## Testing For detailed instructions on testing and configuring your development environment, visit [Testing.md](https://github.com/wordpress-mobile/release-toolkit-gutenberg-mobile/blob/cli/update-checklist/cli/Testing.md). - ## Structure The project is setup wth the following directories: -### bin -The `bin` directory is where the executable files generated by the Go build tools are placed. ### cmd -The `cmd` directory defines the various cli commands that make up the CLI took. Under the hood `gbm` uses [go-cobra](https://github.com/spf13/cobra/tree/main). +The `cmd` directory defines the various cli commands that make up the CLI took. Under the hood `gbm` uses [go-cobra](https://github.com/spf13/cobra/tree/main). ### pkg The packages in `pkg` are intended as the "public" interface for the tool. The are primarily used by the `cmd` packages but could be used by other go projects. @@ -39,4 +76,3 @@ For example using the render package: // this can be called anywhere in the project checklist := render.Render("template/checklist/checklist.html", data, funcs) ``` - diff --git a/gbm-cli/Releasing.md b/gbm-cli/Releasing.md deleted file mode 100644 index 9116b39..0000000 --- a/gbm-cli/Releasing.md +++ /dev/null @@ -1,128 +0,0 @@ -# Release Checklist Template - -The Release Checklist Template can be generated with the following command: (replacing `X.XX.X` with the applicable release number): - -``` -go run main.go render checklist -v X.XX.X -``` - -The `--c` flag will copy the output to your clipboard. To view the output in the command line, simply remove the `--c` flag. - - -If the release is a betafix/hotfix, include a message explaining briefly the reason for releasing the fix. -**Example:** - -``` -go run main.go render checklist -v X.XX.X --message "This hotfix addresses ISSUE_OR_CRASH in ORIGINAL_VERSION. See P2_PR_SLACK_ETC_LINK_OR_LINKS for the rationale behind the decision to make it." -``` - -# Different types of releases - -## Best practices - -It's best practice to use the automation script (mentioned in the release template above) for all releases types (alpha, regular, betafix, hotfix). When wrangling a betafix or hotfix, it's important to merge the fix to Gutenberg `trunk` independently of the release process. When the release is cut (by the automation script) the commit(s) that make up the betafix or hotfix should then be cherry-picked onto the Gutenberg release branch. - -## 1. Alpha - -### When - -Whenever a build is needed for testing (usually a few days prior to a Regular release). - -### Branches - -For example, when the next release will be `1.11.0`. - -| Repo | Cut From | Branch Name | -| ---------------- | -------- | ----------------------------------------- | -| gutenberg | trunk | rnmobile/release_1.11.0-alpha1 | -| gutenberg-mobile | trunk | release/1.11.0-alpha1 | -| WPAndroid | trunk | gutenberg/integrate_release_1.11.0-alpha1 | -| WPiOS | trunk | gutenberg/integrate_release_1.11.0-alpha1 | - -### Automation script differences - -Compared to a Regular release, the differences here are: - -- When the script asks for the new version number, don't forget to add the `-alpha` suffix (e.g. `1.11.0-alpha1`). -- All PRs created by the release script should be edited to clarify that they are temporary and will be deleted when testing is finished. - -### Release checklist template differences - -The release checklist is not used for alpha releases. When testing is finished, please close all PRs and delete all branches created by the script. - -## 2. Regular - -### When - -On Thursdays, the week before the main apps (WPiOS & WPAndroid) have cut their releases, every 2 weeks. - -### Branches - -For example when releasing gutenberg-mobile `1.11.0`. - -| Repo | Cut From | Branch Name | Merging To | -| ---------------- | -------- | ---------------------------------- | --------------- | -| gutenberg | trunk | rnmobile/release_1.11.0 | trunk | -| gutenberg-mobile | trunk | release/1.11.0 | trunk | -| WPAndroid | trunk | gutenberg/integrate_release_1.11.0 | trunk | -| WPiOS | trunk | gutenberg/integrate_release_1.11.0 | trunk | - -## 3. Betafix - -### When - -A fix is targeting a main app version that is not yet released (meaning the release branch is cut but it's still in beta) and a new gutenberg-mobile release is needed. - -### Branches - -For example when releasing gutenberg-mobile `1.11.1` while main apps version `22.2.0` is in beta which currently has gutenberg-mobile `1.11.0` in it. -At the same time there could also be a regular release going on for example for gutenberg-mobile version `1.12.0`. - -| Repo | Cut From | Branch Name | Merging To | -| ---------------- | ----------------------- | ---------------------------------- | ---------------------------------------------------------------- | -| gutenberg | rnmobile/release_1.11.0 (tag) | rnmobile/release_1.11.1 | trunk & (maybe also) rnmobile/release_1.12.0 | -| gutenberg-mobile | v1.11.0 (tag) | release/1.11.1 | trunk & (maybe also) release/1.12.0 | -| WPAndroid | release/22.2.0 | gutenberg/integrate_release_1.11.1 | release/22.2.0 & (maybe also) gutenberg/integrate_release_1.12.0 | -| WPiOS | release/22.2.0 | gutenberg/integrate_release_1.11.1 | release/22.2.0 & (maybe also) gutenberg/integrate_release_1.12.0 | - -### Automation script differences - -1. Run the CLI tool as normal -1. When asked by the script enter the relevant branch names to cut from (to target) in other repos. -1. If a commit that is fixing the issue is already merged to gutenberg, when asked by the script enter the commit hash to be cherry-picked. - -### Release checklist template differences - -1. Include `Betafix` in the heading. -1. `after_X.XX.X` branches can be ignored. - -## 4. Hotfix - -### When - -A fix is targeting a main app version that is already released and a new gutenberg-mobile release is needed. - -### Branches - -For example when releasing gutenberg-mobile `1.11.1` while main apps version `22.2.0` is released which currently has gutenberg-mobile `1.11.0` in it. -At the same time there could also be a regular release, a betafix or even another hotfix going on for example for gutenberg-mobile version `1.12.1`. - -| Repo | Cut From | Branch Name | Merging To | -| ---------------- | ----------------------- | ---------------------------------- | ---------------------------------------------------------------- | -| gutenberg | rnmobile/release_1.11.0 (tag) | rnmobile/release_1.11.1 | trunk & (maybe also) rnmobile/release_1.12.1 | -| gutenberg-mobile | v1.11.0 (tag) | release/1.11.1 | trunk & (maybe also) release/1.12.1 | -| WPAndroid | release/22.2.0 | gutenberg/integrate_release_1.11.1 | release/22.2.1 & (maybe also) gutenberg/integrate_release_1.12.1 | -| WPiOS | release/22.2.0 | gutenberg/integrate_release_1.11.1 | release/22.2.1 & (maybe also) gutenberg/integrate_release_1.12.1 | - -### Automation script differences - -1. If necessary create new patch version branches `release/X.Y.1` in WPiOS and WPAndroid. - -The rest should be same the as Betafix. - -### Release checklist template differences - -1. Include `Hotfix` in the heading -1. After the fix is merged and if there is an ongoing regular release, betafix or hotfix then the changes should be brought back to those branches as well. - -The rest should be same the as Betafix. \ No newline at end of file diff --git a/gbm-cli/bin/.gitkeep b/gbm-cli/bin/.gitkeep deleted file mode 100644 index e69de29..0000000 diff --git a/gbm-cli/cmd/root.go b/gbm-cli/cmd/root.go index 197af17..38d39f9 100644 --- a/gbm-cli/cmd/root.go +++ b/gbm-cli/cmd/root.go @@ -5,21 +5,35 @@ import ( "github.com/wordpress-mobile/release-toolkit-gutenberg-mobile/gbm-cli/cmd/release" "github.com/wordpress-mobile/release-toolkit-gutenberg-mobile/gbm-cli/cmd/render" "github.com/wordpress-mobile/release-toolkit-gutenberg-mobile/gbm-cli/pkg/console" + "github.com/wordpress-mobile/release-toolkit-gutenberg-mobile/gbm-cli/pkg/gh" ) +const Version = "v1.2.0" + // rootCmd represents the base command when called without any subcommands var rootCmd = &cobra.Command{ - Use: "gbm", - Short: "Gutenberg Mobile CLI", + Use: "gbm-cli", + Short: "Gutenberg Mobile CLI", + Version: Version, } func Execute() { err := rootCmd.Execute() console.ExitIfError(err) + } func init() { // Add the render command rootCmd.AddCommand(render.RenderCmd) rootCmd.AddCommand(release.ReleaseCmd) + + // Check to see if the user is running the latest version + // of the CLI. If not, let them know. + latestRelease, err := gh.GetLatestRelease("release-toolkit-gutenberg-mobile") + console.ExitIfError(err) + + if latestRelease.TagName != Version { + console.Warn("You are running an older version of the CLI. Please update to %s", latestRelease.TagName) + } } diff --git a/gbm-cli/pkg/gh/gh.go b/gbm-cli/pkg/gh/gh.go index cc6c37d..3269a37 100644 --- a/gbm-cli/pkg/gh/gh.go +++ b/gbm-cli/pkg/gh/gh.go @@ -217,6 +217,17 @@ func GetReleaseByTag(rpo, tag string) (Release, error) { return release, nil } +func GetLatestRelease(rpo string) (Release, error) { + org := repo.GetOrg(rpo) + client := getClient() + endpoint := fmt.Sprintf("repos/%s/%s/releases/latest", org, rpo) + release := Release{} + if err := client.Get(endpoint, &release); err != nil { + return Release{}, err + } + return release, nil +} + func GetPrOrg(org, repo string, id int) (*PullRequest, error) { client := getClient() diff --git a/gbm-cli/pkg/repo/repo.go b/gbm-cli/pkg/repo/repo.go index d24b77e..6a39a66 100644 --- a/gbm-cli/pkg/repo/repo.go +++ b/gbm-cli/pkg/repo/repo.go @@ -8,6 +8,7 @@ import ( const WordPressAndroidRepo = "WordPress-Android" const WordPressIosRepo = "WordPress-iOS" const GutenbergMobileRepo = "gutenberg-mobile" +const ReleaseToolkitGutenbergMobileRepo = "release-toolkit-gutenberg-mobile" const GutenbergRepo = "gutenberg" const JetpackRepo = "jetpack" @@ -51,6 +52,8 @@ func GetOrg(repo string) string { fallthrough case WordPressAndroidRepo: fallthrough + case ReleaseToolkitGutenbergMobileRepo: + fallthrough case WordPressIosRepo: return WpMobileOrg default: