✨(deploy) slack notify authors of deployments

[mlbrgl]

Send Slack notifications when a new content deployment finishes.

• add SLACK_BOT_OAUTH_TOKEN to live.owid.io/live/.env
• deploy https://github.com/owid/ops/pull/127
• notify developers channel new env
• add the command from the test buildkite pipeline to the deploy-code
• and deploy-content pipelines

To trigger a new notification locally:

• set BUILDKITE_DEPLOY_CONTENT_PIPELINE_SLUG=testing-notify-authors-on-slack
• set BUILDKITE_API_ACCESS_TOKEN
• yarn startDeployQueueServer
• update a chart to trigger a new "deploy" (with the queue updated above, this will only trigger a slack notification, and not an actual deploy)

This relies on:

• test buildkite pipeline: https://buildkite.com/our-world-in-data/testing-notify-authors-on-slack/settings/steps
• test lxc container, created with owid-lxc create -t owid-cloudflare-prod matthieu-slack, after replacing the deploy queue cloudflare deploy with notify-slack (see test pipeline)

[mlbrgl]

Current dependencies on/for this PR:

• master
  • PR ✨(deploy) slack notify authors of deployments #3101 👈
    • PR ✨automatically refresh deploy status page #3100

This stack of pull requests is managed by Graphite.

[Marigold]

I couldn't test it on staging because of an error (perhaps it needs to be rebased or the staging server needs to be restarted?). I couldn't make it work on local, but my setup is a bit screwed right now.

The code looks good though! I'm just wondering why don't you send the notification directly (since you already have a connection to slack web api) and instead go through buildkite? (I'm not saying it's a bad thing, you must have good reasons to do it like that)

(On a side note, it'd be nice to have slack info in users table so that we don't have to do the conversion. But it's obviously out of scope and not a priority.)

[mlbrgl]

@Marigold thanks for the review!

it'd be nice to have slack info in users table so that we don't have to do the conversion.

💯

I'm just wondering why don't you send the notification directly (since you already have a connection to slack web api) and instead go through buildkite?

Yes it's true that using the slack API in two different places seems a bit redundant. I prefer going through BK because it makes the pipeline more self-contained. It also makes dealing with errors in this side-effect straightforward: we see them straightaway in context, for free (no additional reporting to set up, and no need to worry about what to report, and what it means for the rest of the code execution).

Another reason was reusability: we might want to notify through slack from other pipelines, and it's convenient to just grap that one-liner and paste it in.

When and if we do save slack IDs in the DB, the reliance on the slack API at bake time would disappear, which might make the slacktee approach even more palatable.

I couldn't test it on staging because of an error (perhaps it needs to be rebased or the staging server needs to be restarted?). I

I rebuilt the server and set up the relevant BUILDKITE_* env vars. Upon saving or updating a new gdoc, notifications are sent.

Note that lightning content updates are currently broken, so they will appear as regular full bakes but support for lightning bakes is there:

[mlbrgl]

Merge activity

• Jan 17, 12:56 PM: @mlbrgl started a stack merge that includes this pull request via Graphite.
• Jan 17, 12:57 PM: @mlbrgl merged this pull request with Graphite.

[Marigold]

Thanks for the explanation; agree with all your points.