Few days ago, I was reading onmyway133’s 2020 year in review blog post. Among other things, I found quite interesting his use of GitHub issues to publish content for his blog.

I’ve been using GitHub Pages for a while now, to host my website (www.enekoalonso.com) and other projects, like Grand Prix Stats website. At the same time, GitHub provides an excellent editor for issues and pull-requests, with drag-and-drop integrated hosting for images, videos, etc. Not only the editor fully supports Markdown, but can add labels (tags) and milestones to issues, and allow other users to comment on.

Sound like a good opportunity for having some fun.

Over-engineering an event based, server-less blogging solution (for fun!)

My goal is to use GitHub issues (would prefer pull requests, but they require repository changes to open one) to generate content for my existing static site on GitHub Pages. I’m quite sure there are many ways to do this, but I want to automate the process end-to-end. I’m ambitious, so eventually I want this process to manage new entries, updates to existing entries and also un-publishing content, in the event I had to.

I started by thinking that GitHub Actions could do the entire thing, and I’m sure it is possible. But, since I love Amazon Web Services, I decided to do that.

Architecture design

Today, I’m going to start by pushing new issues and updates to a queue in Amazon SQS. Then, we will take it from there, step by step.

For now, I’m keeping the source repository (where I’m writing this issue) private, but the goal is for it to be public.

Pushing issue updates to AWS Simple Queue Service

Following the Principle of Least Privilege, we want to create a brand new policy and IAM user to handle the integration from GitHub to AWS. We would want to restrict this user to only sending messages to this specific SNS queue. By doing this, we reduce the potential for damage in the event these AWS credentials were exposed.

Create an SNS queue for receiving updates

Create an IAM Policy with permissions to push to the queue.

Create an IAM user with programatic access and attach the policy

Store AWS credentials secrets on GitHub

Configure the “push to SNS” GitHub Action

We can use issue creation and modification as triggers for this workflow. There are other issue events that we might want to use down the road, like deleted, labeled, unlabeled… For now, we will stick with opened and edited.

name: New Issue

on:
  issues:
    types: [opened, edited]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

jobs:
  pushToSNS:
    runs-on: ubuntu-latest
    steps:
      - uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: $
          aws-secret-access-key: $
          aws-region: us-east-2

      - uses: isbang/sqs-action@v0.1.1
        with:
          sqs-url: https://sqs.us-west-2.amazonaws.com/<your_account_id>/blog-issue-updates
          message: '{ "issueId": $ }'          

Viewing messages in the SQS console

I have made a few updates to this issue since I added the configuration, so now, for each update, I’m receiving a message in the SQS queue.

As we can see, the message contains a JSON payload with the Issue ID, which we can use to retrieve the entire issue details via GitHub’s API. We might be able to push the entire issue in the message, if we can encode the payload properly. I’ll run some tests and see what happens.

Next steps

Now that we can receive messages when GitHub issues are created or modified, here are some ideas on 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 #1)