Build with GitHub actions

[hinerm]

By default, GitHub pages are built with the gh-pages gem which locks in Jekyll to 3.9 - which can be very slow.

We can change the gemfile to use a newer, faster jekyll and experiment with other plugin versions, but the page will still eventually be built on the GH-side with 3.9. So eventually it would be reasonable to migrate to GitHub actions

[mattxwang]

I don't mind taking this on, and can work on it over the next few days - this is also relatively linked to #50. It can also be a follow-up to the discussion I had in gitter about using Gemfile.lock and streamlining the current install-build process.

What I'll probably do:

• first, create a simple CI action that just builds the site - this is great for checking the validity of the PR, since we can now guarantee that all new changes build
• next, create a CI action that builds the site and pushes to gh-pages -> this will require a push-scope security key as an environment variable, maybe @ctrueden?
• finally, create a CI action that runs the tests described in #50 (and others) - this may be the same overall action as the first
• somewhere between these steps, reintroduce Gemfile.lock

I'm also curious if anyone has thought about using Netlify - I personally have great experiences with them, and their deploy preview feature is amazing. Nonprofits/open-source orgs can also apply for a free version of their paid tier services, which is great. If so, this also makes our lives significantly easier: Netlify just handles the prod deploy, and we don't need to create any secrets for the action.

Any thoughts cc: @hinerm @ctrueden?

[ctrueden]

@mattxwang Sounds great! I'd suggest doing the first and third points right away, for validation of changes (although we do need to limit which bin scripts are hooked up until after we've finished fixing all the currently broken links). I'm also fine with the Gemfile.lock getting added any time. Switching to GHA for deployment makes me more nervous: we'll need to introduce a gh-pages branch... Will the repository become more unwieldy with all these deployment commits on that branch? Will push-to-live time get worse? But it's likely worth it... especially now that #132 is a compelling reason to switch over.

About Netlify: I didn't realize they offered free service on the scale we need. But I'm open to it for sure.

[mattxwang]

I'd suggest doing the first and third points right away

Sounds great to me, I'll get started.

we'll need to introduce a gh-pages branch... Will the repository become more unwieldy with all these deployment commits on that branch?

It shouldn't be, as usually these types of pushes force-push and override the previous history; the branch will always have one commit. I have noticed that the repository takes a long clone time already - it might be good to enforce some sort of squash-and-merge strategy (through the GitHub UI) or coalesce some of the previous commits. Using something like Netlify or Vercel also resolves this problem nicely, since they host the final version.

Will push-to-live time get worse?

Shouldn't be, GitHub Pages' auto-use Jekyll feature does the same thing under the hood; in my experience, the actions spinup (minus build time) is ~ 30 seconds.

About Netlify: I didn't realize they offered free service on the scale we need. But I'm open to it for sure.

Sounds good to me, there's no rush but it's a cool service to poke around in! More than happy to take a deeper dive for this too, I use Netlify for another (smaller-scale) nonprofit + OSS org so I have a bit of experience there.