[CEP] Migration alerts before deploy

[esoergel]

Abstract

The aim of this work is to better communicate to deployers what changes are about to be deployed.

We currently use tags on pull requests to flag pull requests that have, for instance, a reindex or migration. This information should be presented to deployers at the very beginning of the deploy process, as part of the “are you sure you want to deploy?” message.

Motivation

Deployers are usually unaware of what exactly they are deploying, particularly as 3rd parties are hosting their own instances, and as the Divisions at Dimagi operate independently. This is intended as a means for PR authors to communicate with deployers.

Specification

Current state

When deploys happen, we use git tags to label the commits that have been deployed to each environment. At the end of the deploy, we then generate a github URL which compares this deploy to the previous one. The deploy scripts then pass this information to a management command, record_deploy_success which emails it to admins, and creates a record of this deploy for later reference.

One glaring issue with this approach is that saving git tags requires write access to the repository, so this is fully off-limits for third-party environments, which deploy the Dimagi-controlled HQ repo. Another limitation is that information about deploys is only presented after the deploy is complete, so it can’t be used to warn of potential concerns or special considerations.

Desired changes

This can happen entirely inside commcare-cloud/fab/.

• Add a function to get a list of PRs between last_commit_sha and deploy_ref.
• Extract tag information for each of these pull requests
• Render this list of pull requests to the console, displaying each PR's name, a link to the PR, and all its tags. If any of those PRs are tagged reindex/migration, add a message in red to the bottom along the lines of "Warning! You are about to deploy the following PR(s), which will trigger a reindex or migration. Click the link for additional context", and repeat those PRs.
• Insert this message here.

Impact on users

None

Impact on hosting

Should reduce the communication gap between code authors and deployers.

Backwards compatibility

Backwards compatible

Release Timeline

Open questions and issues

[millerdev]

+1 I like it.

One glaring issue with this approach is that saving git tags requires write access to the repository, so this is fully off-limits for third-party environments...

Does this CEP address this issue? I don't see how the proposed changes affect it, but I agree that it is annoying (although seems irrelevant here). Maybe it needs a separate CEP?

Edit: I think that other CEP is #27839

[esoergel]

@millerdev

Yeah, I initially thought we'd need to save a commit history in HQ and reference that in order to do the diff. I was like 3/4 of the way through writing this when I saw the fallback clause here - that we can just check against the current code in the repo, and that we already do that 🤦

I do still think saving the commit directly is a saner state for that stuff, but since it's not directly relevant to this CEP anymore, I spun that off separately.

[esoergel]

implemented in the above PRs.