[Tooling] Fix GitHub releases for intermediate betas

[AliSoftware]

Why?

Similar PR than WPiOS's https://github.com/wordpress-mobile/WordPress-iOS/pull/16674

Fix the GitHub releases drafts being incorrect for intermediate betas:

• They used the final version number (x.y) for the release name and tag instead of the build number (x.y.0.N)
• They had the incorrect release notes (used the previous ones for any beta, including the first one, created before we manually update the notes with Editorial copy)
• They didn't have the "Pre-release" checkbox checked on them

To Test

Not easy to test from start to finish without creating a new beta… and we already did the finalize_release for this Sprint so we should not create a new beta even just for testing, so not sure if there's a way to dry-run/test this 😒

Best way I can think of is comment all the steps in the Fastfile that have side effects on build_and_upload_itc (namely gym, testflight and sentry) and trigger the lane with the same parameters that are used in the .circleci/config.yml for beta build, and check the result. But that will only test a tiny portion of the changes, like it won't test that the release notes extraction works to use the right release notes for first betas nor that the round trip from "run lane on your Mac -> trigger CI -> CI run its own lane" doesn't break mid-chain…

So maybe the best way to test this besides just reviewing the code is to test this during the next cycle…

[peril-woocommerce[bot]]

	Warnings
:warning:	PR has more than 500 lines of code changing. Consider splitting into smaller PRs if possible.

Generated by :no_entry_sign: dangerJS

[peril-woocommerce[bot]]

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

[peril-woocommerce[bot]]

You can trigger an installable build for these changes by visiting CircleCI here.

[jkmassel]

Let's try to test this one this cycle (following the code freeze)

[AliSoftware]

@jkmassel feel free to take over the PR and push Gio's suggestions and rebase this after 6.9 code freeze 🙂

[shiki]

Moving this to the 7.0 milestone. :)

[AliSoftware]

@shiki as @jkmassel said above I think the plan is to actually rebase this onto release/6.9 and merge this after code freeze during this sprint, so that Jeremy can test it next during the beta cycle 😅

[shiki]

Lol sorry. I don't know how to read.

[jkmassel]

No merge issues rebasing to release/6.9!

If we need another beta this week, I'll test this PR then. If not, I'll test this PR on its own early next week in a throwaway beta build.

[AliSoftware]

@jkmassel I believe you made a beta recently, were you able to test this fix?

Even if not I think it's worth merging sooner than later because:

• It's starting to have conflicts with the release branch and the more we wait the more conflicts we'll get
• I need to work on the Fastfile (to align hotfix branches) and my changes risk conflicting with the ones in that PR so it would help to apply my changes only after this is merged, which means I'm waiting for this to go forward 😓

[AliSoftware]

@loremattei this was split in two PRs, with the styling separated in #4417 and the fix only in this PR.

But what happened is that #4417 got then merged before this PR, and this made the diff of this PR change and include the changes from #4417, hence the bigger diff when you finally reviewed, while the original intent was to review (and potentially merge) this PR first and #4417 next, which would have kept the diffs separate as it originally was and as intended.