Rather than digging through the github context in YAML, I decided to use toJSON() to encode the entire context and send it to Amazon SQS.

message: ${ { toJSON(github) }}

Still not sure if that will provide enough information to identify the Activity Type being performed in the issue.


It’s been a busy day, but now I’m back at it. After testing this new flow, sending the entire JSON payload to SQS, looks like github.event.action contains the Activity Type. This means that with a single workflow, I can control on the AWS side how to react depending if action being taken in the issue (opened, edited, closed, labeled, unlabeled…).

Eventually I want to look into issue comments, but for that, I’ll probably define a separate workflow. We will see.

Update 2

It seems I won’t be using my GitHub Graph API client, at least not for now, since the SQS message will contain the entire event, including all issue details.

Next steps

  • Configure GitHub action to push Issue updates to Amazon SQS (#1) ✅
  • Configure an AWS Lambda to process the incoming messages (#2) ✅
  • Retrieve entire issue details via GitHub Graph API, or embed in message (#3 & #4) ✅
  • Automate creation of blog post on GitHub pages (via direct commit, or pull request) (#7 & #9) ✅
  • Send me a notification via email or SMS with the url of the new blog post (using AWS SNS)
  • Potentially store a mapping of GitHub issues to blog URLs (and file paths) on a DynamoDB table

This article was written as an issue on my Blog repository on GitHub (see Issue #4)

First draft: 2020-12-22

Published on: 2020-12-23

Last update: 2021-01-05