Build and deploy using GitHub Actions

[timwis]

JKAN gets built using GitHub's built-in Jekyll builder. This is what enables such an easy setup process for JKAN. But it also puts a ceiling on some of the features and customisations we can do. The built-in Jekyll builder comes with some great plugins, but we weren't able to use any plugins beyond that without leaving the GitHub ecosystem and using a third-party product (e.g. Travis CI) to do the builds, which would have increased the installation and maintenance complexity.

Since JKAN was originally developed, GitHub have released GitHub Actions, which let you run your own custom build code. I believe they actually run the built-in Jekyll builder on GitHub Actions now, which is why you can see the build results in the 'Actions' tab of your JKAN repo.

If we create our own GitHub Actions workflow file, this would give us full control over the build process, which would let us pull in custom plugins (and let downstream users do the same). It would also give users the option of more easily deploying to other hosts. This looks like the official action to deploy the built site to GitHub Pages, and assuming we pull in the pages gem, we'd have all the same default Jekyll plugins.

This seems like a win-win solution, but I thought I'd ask if anyone could think of any reason not to?

[BryanQuigley]

Happy to move to this - I'm somewhat partial to do it using the docker based workfllow so we can fully reproduce it locally.

I've done a few Jekyll sites and haven't found the need to do this, but I have lots of other sites using other static generators and it works fine there... Maybe wait until there is a specific thing we can't do in the current setup?

[timwis]

Just wanted to share two related updates:

1. GitHub released official support for deploying to GitHub Pages via GitHub Actions in July 2022, and appear to be moving toward that over the github-pages gem.
2. Per Review and decide on the Netlify CMS backend & auth options #204, we'll soon be recommending Netlify as the default hosting option.

We still want to support GitHub Pages, but if we use the GitHub Actions approach, it would unlock the ability to add plugins. This would be helpful not just for big features, but also for adding useful liquid filters, so we don't have to resort to complicated workarounds.

[BryanQuigley]

I had to just move another project over git GitHub Actions approach - it worked great. They even call the previous approach "Classic GitHub Pages" now. I'm for just moving over to the GitHub Actions workflow, it should make things a bit easier/future proof.