Blog Flow

One of the things I gave up when I dropped Django in favor of the static site generator Hexo was the ability to have background tasks and webhooks to react to when a post is published. Previously, I had a Django Post Save Signal Handler that posted a link to the article on Twitter.

Now with my static site generator, I not only have to setup a separate flow for posting to twitter, the deployment process now needs to be setup. Here is my setup and thoughts and reactions to it.

Setup

First and foremost, the entire project is version controlled in git. For a few years now, every single piece of work effort I have contributed to has been in source control. The safety and options it gives me is something I would dream about producing any work without.

The host for this project’s git repo is GitLab. I have moved most of my projects from github to gitlab recently due to a mix of cost and feature reasons that I will get into in another post.

The GitLab repos is setup with a GitLab CI runner. The config for said runner is as follows:

image: mc706/gitlab-angular2-awscli

stages:
  - deploy
  - cleanup

deploy:
  stage: deploy
  before_script:
    - npm install
    - npm install -g hexo
    - aws configure set preview.cloudfront true
  script:
    - hexo generate
    - aws s3 sync --delete public s3://xxxxxxx
    - aws cloudfront create-invalidation --distribution-id XXXXXXXXXXXXXX --paths / /* /index.html /2017/* /search.xml /sitemap.xml /tags/* /search/* /css/* /images/* /js/* /lib/* /about/* /archives/* /projects/*

  artifacts:
    expire_in: 1 week
    paths:
      - public

cleanup:
  stage: cleanup
  script:
    - rm -rf node_modules
  when: always

The basic gist is :

• Use a Docker Image gitlab-angular2-awscli. This is a docker image I authored that has node:lastest and the python awscli installed
• Install requirements for the project
• Install hexo globally
• Setup the AWS CLI to allow for the cloudfront preview
• Generate the static site
• Deploy it to s3
• Invalidate the cloudfront distribution.

• Cleanup

  This allows me to push to gitlab, and the gitlab runner will automatically build the project and publish it my AWS instance. It invalidates the cloudfront cache to allow the latest versions of files to be available.

Posting To Twitter

Posting to twitter was a harder problem to solve. This was done with a mix of GitLab Issues, Some process, and Zapier.

To start off the twitter flow, whenever I have an idea for a blog post, I run hexo new draft <idea>. This creates the appropriate files and folders in the _drafts folder. After doing so, I go into GitLab Issues, create an Issue with the title of the post, and a short description about the post. I label that issue with the label Post.

Throughout the week, I will pick a topic in the _drafts folder, build out an outline, and fill in the body of it. Once I am ready to publish the post, I run hexo publish <idea>, and it will move the folder and markdown file accordingly.

When I got to commit the idea, I use gitlab issue’s integration to do an auto close on commit. In the commit message, I include a closes #<issue_number>, which, when pushed, will close out that issue.

The issue with Label Post closing triggers a free Zap in Zapier, which recieves the gitlab issue object in a webhook. I can then pull out the title of the article (from the title of the issue), insert it into a form, and add the extra text from the description to the issue to the end of the template. Zapier will then tweet that out for me while the CI is building.

Improvements

I am thinking of adding a delay to the twitter post in case the build time of the static site begins to increase with time. That or see if in an deploy stage of the build if I could trigger the tweet.

The other issue is due to the nature of the information passed round, the script never knows the Url of the post just posted. Instead, the tweet just links to the root of the site, which will have the latest article on top.