You can as well build the site locally (e.g., on your computer) first and commit the .html files in your page repo. GitHub pages will then serve your .html files directly without having to build your site using Jekyll. This is what I used to do when hosting my site on github pages:
- locally install jekyll
- write my .md files
- run jekyll locally to see how my site looks like
- commit .md and .html files
- let github pages know what you are pushing the static files yourself
- The version of Jekyll that builds your site at deployment time (say at CI integration) is managed by Github including security updates
- If you install Jekyll into the repo (which you don't need to) for local testing you will add a bundler bundle file
- If you have a bundler bundle file in a public repo you will get automated Dependabot pull requests to suggest to update the file as security notices happen
- These updates affect your development environment version as specified in the repo, not the version managed in the build process
Up until recently the whole process was somewhat opaque, but it looks like the "Jekyll build process" is slowly migrating into Github Actions (with everything else) and there's a lot more visibility into its workflow than ever before. In a recent repository it seemed even more clearer than before that the Jekyll version in the "Github Action workflow" was Github-managed wasn't directly the Jekyll version specified in the code repository.
