gbm CLI checklist marks "Create an Aztec Release" section conditional

[dcalhoun]

Historically, the "Create an Aztec Release" has been considered and marked as conditional, but it is not currently present when generating a release checklist with the gbm CLI.

Create an Aztec Release (conditional)

[jhnstn]

The optional sections – both "Aztec" and "Incoming Changes" – rarely get used.

I believe there was some agreement that we can fully remove the "Incoming Changes" section. "Incoming Changes" lost importance after we shortened the time between cutting and integrating releases. We should probably just capture an updated "Incoming Changes" set of steps in the release documentation.

The Aztec section should still be there but the "(condtional)" part might be missing.

I was working on an Aztec validator function as part of the release building scripts. I planned to use it during the checklist rendering to decide if the "Create an Aztec Release" section is needed. It's a bit tricky since the checklist is published early in the release week. So things could change by Thursday. Again, that rarely happens so not sure we really need that section.

One idea I had was to allow the cli to render just the Aztec update steps on their own. That way a wrangler could generate those steps and add them to the release post as needed; either by updating the post or adding as a comment.

[dcalhoun]

IIRC this issue was only attempting to note the "conditional" label was missing from the referenced sections.

Automating the Aztec check would be great. The thoughts on dropping "Incoming Changes" are interesting and likely worth a broader discussion with the team.

[jhnstn]

This is resolved in https://github.com/wordpress-mobile/release-toolkit-gutenberg-mobile/pull/146

I've added a flag --a which will have the script check if the Aztec config is pointing to a production build. If Aztec is good, it will not add the conditional "Update Aztec" steps. It will still include the verification step in the "Create the Release" step. The anchor to the update steps will be invalid in this case but I've opened an issue to address that.

Now the Aztec config can change between generating the list and creating the release. This is rare but pre checking Aztec during the checklist generation will mean there are no steps to follow to create an Aztec release. As a fix I added a render aztec command to the CLI to generate the Update Aztec steps. This can then be added to the original release checklist post or added as a comment.

For now the default is to render the checklist as-is which includes the conditional Aztec steps (I made sure to add back the "conditional" copy in this default case) Eventually I'd like to flip the default so that it always checks Aztec but I think we should wait till we clean up the documentation around that first.

The thoughts on dropping "Incoming Changes" are interesting and likely worth a broader discussion with the team.

I haven't made any changes there but will open an issue to discuss excluding that section. Much like the Aztec steps, it would be easy to add a command to render those steps.