Repository navigation
Build with GitHub actions #92
Description
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
Activity
mattxwang commentedon Jun 1, 2021
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.lockand streamlining the current install-build process.What I'll probably do:
gh-pages-> this will require a push-scope security key as an environment variable, maybe @ctrueden?Gemfile.lockI'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 commentedon Jun 1, 2021
@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.lockgetting added any time. Switching to GHA for deployment makes me more nervous: we'll need to introduce agh-pagesbranch... 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 commentedon Jun 1, 2021
Sounds great to me, I'll get started.
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.
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.
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.