Hey y’all. Congrats on 4.0 and thanks for having the forum. Spent the past few days on here and stackoverflow getting some of my sites updated and they’re finally done! I saw posts like this one /github-pages-and-jekyll-4-0-0/3471 (sorry i can only put two links in a post I’m new) who are upset that GitHub Pages is missing a lot of features which bottlenecks Jekylls potential.
TL;DR
Using any devops tools like Jenkins, CircleCI, GitHub actions allows you to add a layer of automation between your commits and deployment. That layer is simply automating one of those platforms to build the site source, and then push it as a commit to a separate branch on GitHub where it will publish it exactly the same as if you had let GitHub do the build. The different is in the CI environment you have control over everything. the jekyll version. the plugins. using other gems to manipulate the site source, or do other quality checks. It’s not exactly a novel idea, but I’ve included a CircleCI example config that you can copy/paste as well as code snippets for running some basic QA checks on your produced source files. which you can run locally as well.
Any feedback on the articles is surely appreciated as well!
Unfortunately as far as I can tell, Github Pages chooses 3.8.x for you and this cannot be overridden with Gemfile or config. https://pages.github.com/versions
I switched one of new projects to jekyll 4 by specifying it in Gemfile and doing a Netlify build.
I use Netlify for some projects rather than Github Pages. One reason is the build log is verbose and I have control over the build command. Also there is a rebuild button which does not require a commit. You can share the build log with others if set to public and you can build Pull Requests as deploy previews which I found super useful lately.
Plus in Netlify you can could specify tests as part of the build command.
I recently also found a Ruby gem which I ran locally to check for any broken links on a site and potentially this could be added as part of a deploy workflow.
I may have explained it poorly. The method I describe in the blog posts outline how you can avoid the limitations of GitHub Pages by using CircleCI to build the site with Jekyll in CI and then publish the fully built site to GitHub Pages. And in the CI environment you can use Jekyll 4.0 and anything else. I’ve added some very basic QA validation as well that prevents the site from being deployed with errors that can hurt SEO or UX.
Okay I see. So your code is on one branch and built site on another, or different repos? I saw something for react which compiles and builds and publishes to different branch so one can use something not normally possible on GH pages.
Yes, in GitHub pages you can have the source code live in the master branch, for instance, and build/push the website to a separate branch. Then you tell GitHub to serve from the branch with the fully built site rather than the source. and you can use any version of Jekyll, or any gems/plugins that are available without issue but still host on GitHub pages.
What tells GitHub to serve from the gh-pages branch versus the master branch? I have a user site <user>.github.io and it looks like the settings page says it can only be served from master for User pages. But I have set my gh-pages branch as Default – I think this just means this is the branch that it shows when someone visits the repo and/or downloads/clones it for the first time.
You could maybe even simplify matters by using GitHub Actions directly instead of CircleCI. I’m not sure if GH Actions makes it easy to commit changes to another branch as part of the workflow, but if so that’d be a pretty nifty setup.
That’s dope. GitHub Actions would totally work as well. Any CI would work really but I had the most experience with CCI so I went with that. But I think GHA is probably easier given the goal here. Nice docs!
Thank you for sharing this and I really appreciate it! I am still learning GitHub Actions and to be honest, as an occasional developer, it is a little daunting.
From what I am reading, your code gets the latest build from the master branch and then publishes it to the gh-pages branch. The use case is to allow for custom plugins, which I appreciate.
What I would like to do is just have the code re-deploy the master branch every night. I am looking for this based on a previous discussion with you where we talked about re-building a site so I can always get the latest posts based on whatever “today’s” date is.
Here is the research I have done so far. I think I can use an on.schedule cron job that, say runs every day at midnight, like this: 0 0 * * *
I also know that when I push my code from my local repo to the remote GitHub repo, a github-pages deployment occurs.
That re-deployment of master is what I want to re-create, but just without me having to make changes to the code for that to happen.
Could you shed some light on how I can use GitHub Pages to re-build my site based on the master branch?
I also cover some recommended flows for GH Actions and GH Pages builds here, for Jekyll and other tools. Rather than finding a specialist Jekyll action like in the tutorial, this follows a more generalized approach.
