Hosting On Github

Introduction

Typically, if you wanted to host something on GitHub Pages, you’d create a repository with the name my_github_username.github.io, write your Markdown or HTML documents as pages or posts, and then commit those changes and push them to the repository. When GitHub realizes the repository is a GitHub Pages repository, it runs some site-building procedures using its “continuous integration” (CI) to rebuild your website from those Markdown or HTML pages each time you push a new commit to the remote repository.

But I’m built different. I am not writing Markdown or HTML documents. I’m writing Org Mode documents and then exporting them to HTML documents. Because the Org Mode documents need to be exported by Emacs in order for GitHub Pages to render them as pages on the site, we need to explicitly tell GitHub pages what to do. Thankfully, SystemCrafters has a video that covers this.

Specifying the Automated Workflow

What we need to do is provide GitHub’s continuous integration the specific steps required to build this site. This is done through the file .github/workflows/publish.yml stored in the repository’s root directory.

With this file, we can specify when want to perform this task. For a static website, I really only need to do this each time I update the remote repository, so we set that as the trigger for the workflow. Additionaly, we need to specify which Git branch triggers this task. In my case, this is master. GitHub is moving away from using master as the default branch name, but the default CI for GitHub pages expects a branch name “master”. We aren’t using the default CI, so we can actually afford to change this. I’ll handle that at a later stage. For now, I just want to make this work.

# Give the job a name
name: Publish to GitHub Pages

# Specify when to perform this task
on:
  push:
    branches:
      - master

Next, we need to specify how to run the workflow. First, we want to run the workflow on a virtual machine running the latest version of Ubuntu, which we accomplish by specifying runs-on as ubuntu-latest. We also need to check out the code for running on the VM, install a minimal Emacs that will run our script, run the build script that we built in the initial build set up, and then publish the pages using a community developed action. This community action will ultimate create a new branch, gh-pages, where our exported pages will live.

Note: These steps will likely change as new steps are added, like Jekyll integration. For now though, this will get our initial site published using GitHub Pages.

# Specify the steps, in sequential order, to perform
jobs:

  publish:

    # Use the latest version of Ubuntu for the VM
    runs-on: ubuntu-latest

    steps:

      # Check out the code to be run on the VM
      - name: Check out
        uses: actions/checkout@v1

      # Install a minimal Emacs
      - name: Install Emacs
        run: sudo apt install emacs-nox --yes

      # Run the build script
      - name: Build the site
        run: ./build.sh

      # Publish the site using a community deploy action
      - name: Publish generated content to GitHub Pages
        uses: JamesIves/github-pages-deploy-action@4.1.4
        with:
          branch: gh-pages
          folder: public

After we push a new commit with this new file added. GitHub will perform these tasks. There’s just one more requirement before this produces a published page. On the GitHub repository web page, go to Settings > Pages and then in the “Branch” section, change the branch to gh-pages. After this, the web page should show your published content. It may take a couple minutes to load, though.