[Tooling] Create a Single, Unified GitHub Releases for WP Alpha, WP Beta & JP Beta

[AliSoftware]

This is part of project paaHJt-2s9-p2

ℹ️ This PR targets release/18.2 in the hope I get the occasion to use it in this release in case it's merged in time.

What it does

Now that #15273 has been merged and the 3 Release Builds (WP Alpha, WP Beta, JP Beta) are done in parallel, this PR is now able to create a single GitHub Release for all 3 builds, instead of creating one GitHub Release for each like before.

How

• Refactor the create_gh_release lane to be able to include multiple assets for multiple apps and versions at once, merging release notes as necessary into one description.
• Update the YARD doc of build_* lanes to mention the app: parameters and update their call to create_gh_release
• Update the .circleci/config.yml file to call create_gh_release with the 3 build artifacts only created once the 3 parallel builds have finished.

To Test

• Run git checkout -b ci-test/pr15319 origin/jetpack-infra/unified-gh-release^1 to cut a new branch from the commit before the tip of this one.
  • This will include the debug commit 1e5c779 – which changes the versionName to a dummy 18.2-rc-999, and disables upload_to_playstore:true and the slack action – but not include the last commit of this branch which reverts those debug changes.
  • This is done to avoid noise during testing, but also to ensure the test GitHub Release gets a new name (instead of being auto-matched with existing tag 18.2-rc-3), and so that the builds won't fail with "versionCode already exists in PlayStore"
• Push your new test branch to origin: git push -u origin ci-test/pr15319
• Trigger a release build: bundle exec fastlane trigger_release_build branch_to_build:ci-test/pr15319
• Wait for the CI workflow to finish, then check that a single, unified GitHub Release draft has been created.

The generated GitHub Release draft should:

• Point to the commit sha1 of your ci-test/pr15319 branch, which should be 1e5c7795f269cb7e340bb9405dadd11839d59b4f
• Be titled "18.2-rc-999"
• Contain BOTH the WordPress and Jetpack release notes or 18.2 – as found in WordPress/{metadata,jetpack_metadata}/release_notes.txt files
• Contain the 3 .aab artefacts (WP Alpha, WP Beta, JP Beta)
• Be marked as "This is a pre-release"

Screenshot of the expected GitHub Release draft

Cleanup

• Delete your ci-test/pr15319 branch from origin.
• Delete the draft GitHub Release named 18.2-rc-999.

[peril-wordpress-mobile]

You can trigger optional UI/connected tests for these changes by visiting CircleCI here.

[peril-wordpress-mobile]

You can test the changes on this Pull Request by downloading the APKs:

• Jetpack-pr-15319-build-115382.apk
• WordPress-pr-15319-build-115382.apk

[mokagio]

This is very neat. Blown away by the speed at which CI built. I went on the tab to check on the progress and it had already finished! 🤯

I verified the generated release matches the expectation 👌

Not sure what your plans for merging are. In case you haven't thought of it already, I'd suggest rewriting the history to drop the last two commits.

[AliSoftware]

This is very neat. Blown away by the speed at which CI built. I went on the tab to check on the progress and it had already finished! 🤯

Yep, definitively! Having this project done (paaHJt-2s8-p2 + paaHJt-2s9-p2) will change my life as Release Manager!! I'm so happy for this change, no more spending the whole morning waiting for CI (and having to wait for WP CI to finish before I need to trigger JP CI) and no more having to do half of the tasks by hand anymore 🎉 #relief

Not sure what your plans for merging are. In case you haven't thought of it already, I'd suggest rewriting the history to drop the last two commits.

Yeah I did it that way because last time I used a debug commit like that, the PR was accidentally merged before we pushed back the revert commit, so I figured it was better to include the debug commit and its revert this time, and ask you to point before the revert commit.

That being said, I think I'll keep those 2 commits in the merge, because rewriting history to drop them would make the PR description invalid if I did, and it can still make sense to keep track on how the PR was tested. Not a big deal once the PR is merged you'd say, and I can also see the value in keeping the git history cleaner, but I still like to keep consistency in the PR comments and desc even post-merge, in case we need to come back to this PR later one day and need to make sense of it 🙃

[peril-wordpress-mobile]

	Warnings
⚠️	This PR is assigned to a milestone which is closing in less than 4 days Please, make sure to get it merged by then or assign it to a later expiring milestone

Generated by 🚫 dangerJS