AWS Amplify Deploy Notifications
Amplify has a notifications mechanism (email) that sends you build notices. However, these notices have typos in the URLs they include, as well as they don’t incorporate your custom domain. Here’s one way to address that.
I’ve been using AWS Amplify Console to deploy a frontend app. Amplify has multiple components, so this is specifically about the Console piece, which deploys static web apps to S3+CloudFront. Amplify has some great features, including creating separate (subdomain based) deploys for every branch or pull request you create. You can configure this via patterns, to control whether all or only branches with certain names see this, etc. There are a ton of other great features going on around this as well. All this is further tied to your custom domain(s) that you can configure.
That said, Amplify’s email notifications, the only kind easily added, have a bug in terms of the URLs they send. The URLs use the branch name, but often branches will have slashes, periods, or other characters that don’t work in URLs, such as: “feature/my-new-feature” or “release/1.2.3”. Their deployment system substitutes dashes in for these, but they didn’t seem to carry that through to the email notifications. I filed a GitHub issue for this, but there has been no action on it.
To somewhat remedy this, I created a GitHub Action that sends the URL for the Amplify deploy to Slack when the branch is created, and adds a comment with the URL when a pull request is opened. This gives us an readily available link in places easily accessible or in the context of the PR. Note, that this action generates the URL itself vs. using the email or something from AWS, etc., but they are consistent, so it works fine.
GitHub Action
Here’s the Action, with some comments after. I hope this helps others using Amplify :)
First, note that this action runs on branch create, and when a pull request is opened. For branch creation, it notifies Slack of the URL. For pull requests, it adds the comment (but does not notify slack, since that was already done with the branch). You can obviously adjust this as you see fit.
GitHub Configuration
You need a GitHub access token to use with the GitHub Comments API that injects the URL as a pull request comment. The only permissions it needs are repo. Create this in your GitHub Settings > Developer Settings > Personal access tokens. e.g.:
Next, I’m using the GitHub Secrets feature to securely store this token in my organization’s secrets, but make it available to the action (you’ll see this referenced in the action as secrets.GH_ACTIONS_API_TOKEN). See that link for creating a secret (it’s very easy). This is then made accessible to the action’s shell script code via an environment variable called GH_API_TOKEN (see second from last line of the action code).
Slack Configuration
To notify Slack, you need to create a Slack app, and turn on its webhook integration. This provides you a URL that you can send a message to via curl as the action does. This is the simplest way to do it (vs. using the OAuth user messaging). I found this article was a nice step-by-step on setting this up, and it’s quite easy (don’t fear it — it takes all of about 2 minutes to do it!).
From that, you need your webhook URL. Again, I’ve stored this as a GitHub secret, which is referenced as secrets.SLACK_DEV_NOTICES_WEBHOOK, and then set to the SLACK_WEBHOOK environment variable. For your Slack app, you’ll do this on the “Incoming Webhooks” setting, and the URL you want is the “Webhook URL” as pointed to below:
Branch/Domain Customization
Finally, the action above does some somewhat kludgy setting of the domain name to use. We use different AWS accounts for dev/staging/production etc. environments, and have different domains in use for those. As you’ll see in the action, this uses one domain for “release/*” named branches, and another for all the other branches (I should probably add “hotfix” to the releases one, but haven’t had to use that yet :)
The branch name is obtained from the GITHUB_REF environment variable, which looks like “refs/heads/<branchname>” and thus the syntax used there is stripping off that “refs/heads/” portion. Similar techniques are used to get the pull request number (also from the GITHUB_REF when it’s a pull request), and the branch name out of the GITHUB_HEAD_REF again in the case of a pull request.
Lastly, you’ll see the if conditionals in some of the steps, which is how the branch vs. pull request behavior is controlled, as well as the environment/domain config as just described. And, within those, you’ll notice the use of the “context”, and that GitHub provides some functions you can use for simple things (e.g. the “contains” function used to check for a substring in one of the context values). See GitHub’s context and expression syntax docs for more on this.
Update 19 Aug 2020
Note, I added one more tweak, which is for when a new tag gets created (this is triggered by the same “create” event (both branches and tags trigger that). Thus, I check this and notify Slack that a new production deploy is available, as that’s what we’re doing with the tags right now (so you might have to make that more specific if you use tags for other things as well).
Last Words
I’ll note that you could also implement the functionality of this with a bash script that you just have the action run. I’ve been exploring GitHub actions more, and wanting to learn the various abilities it has, so this was done somewhat as an exercise to try these features out. It also turned out that these notifications wound up being quite simple to implement (single curl commands, with a little bit of surrounding setup). I had also not previously seen GitHub Secrets, or used the conditional aspects of Actions. All-in-all some fun learning.
