Closed jhnstn closed 1 year ago
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
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 butpkg
is a common directory to use for internal packagestemplates
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 liketemplate.html.irb
cmd
This is where the CLI command live. The structure uses the recommended command structure fromcobra
Supported command
This PR only introduces one top level command
render
. To see it's usage rungo run main.go render -h
from the project rootCurrently the command supports 2 sub commands
checklist
andaztec
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 menugo 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 thechecklist
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
go run main.go render
to run either of the two render sub command.checklist
command.--c
command to have the command write the checklist to the system clipboardThere are unit tests which can also be ran. I recommend using the Goloang extensions for vscode to run the tests.