CLI: Add gbm cli tool with checklist rendering command

[jhnstn]

This is the foundational work for adding a Go based CLI tool for handling GBM releases.

Project Structure

pkg/ these packages are used internally within the project. Go does not have a set pattern for a project structure but pkg is a common directory to use for internal packages

templates These are go templates. The main file embeds these files into the binary so that they can be referenced by the relative project root path e.g. templates/checklist/task.html (Go templates do not use a specific file extension pattern like template.html.irb

cmd This is where the CLI command live. The structure uses the recommended command structure from cobra

Supported command

This PR only introduces one top level command render.
To see it's usage run go run main.go render -h from the project root

Currently the command supports 2 sub commands checklist and aztec

command requires a release version -v 1.0.0
If passed a scheduled release version i.e. 1.0.0 the generated checklist will show scheduled release related steps.
if passed a patch release version i.e. 1.0.1, the generated checklist will show patch related steps.
There are a few other flags available that are listed in the command help menu go run main.go render -h

checklist.html - This template generates a release checklist using Gutenberg Task blocks instead of the markdown checklists. Besides the variance in type of release, the rest of the steps should be the same in practice as the existing checklist. There are a few other changes such as removing the message about the source of the checklist and adding a tag and cross post to the bottom of the post. These changes are make the checklist more consistent with other mobile release checklists.

Aztec

In most release scenarios Aztec is not updated. The result is that we end up leaving the conditional "Update Aztec" steps unchecked. By default the checklist command keeps the conditional steps. There is a flag however that changes this behavior. adding --a to the command remove the conditional Aztec section. It also makes the script reach out to the relevant Aztec configs to see if a release version is required. In this case the checklist command will add the Aztec steps to the checklist but right after the "Before the Release" section. It also adds a warning message about updating Aztec.

Now since the checklist is generated days before cutting the release, it's possible that an Aztec update is required at the release cut time. To handle this case the render command has an aztec command to render the aztec steps. This. block of content can be added directly to the checklist or added as a comment. Which is best is TBD.

Testing

• Use go run main.go render to run either of the two render sub command.
• Try pasting the output in a P2 editor
• Verify that all the block render correctly
• Verify that all the relevant release steps are correct when using the checklist command.
• Try using the --c command to have the command write the checklist to the system clipboard

There are unit tests which can also be ran. I recommend using the Goloang extensions for vscode to run the tests.

[derekblank]

This looks like a great start. Given the docs, I was able to run commands like go run main.go render checklist -v 1.105.1 and review the output successfully. I would be in favor of merging this and iterating from there, particularly since the existing release script (release_automation.sh) can still be executed.

I added a commit to resolve some typos mentioned in #147, mostly as a means to get some code familiarity.

I think the eventual goal is that a command like go run main.go render checklist -v 1.105.1 would create the actual P2 post via automation, and I think you'd agree. Approving this to iterate on in the meantime.

[jhnstn]

I think the eventual goal is that a command like go run main.go render checklist -v 1.105.1 would create the actual P2 post via automation, and I think you'd agree. Approving this to iterate on in the meantime.

100% agree. I'll put an issue for posting to a p2 via the script on the backlog