On my last contract I was hired to automate things with Powershell, which until that point I had used sparingly, only in niche situations where I wanted a list output of, e.g. Active Directory objects. During this time I grew to appreciate the tooling around it, that cmdlets - the various tools written in powershell or C# using the .NET/core system libraries - consistently behaved nicely with a shared typesystem and outputs. I still have a love-hate relationship with Powershell, but like Perl, it’s a much nicer language than the previous shell language.
It turns out that configure pages was mostly bust. I don’t need it whatsoever for building and testing jekyll with all the dependencies and plugins that github-pages uses/allows.
So I moved on to actions-jekyll-build-pages. This is where the juicy stuff is, as far as I can tell.
So the callGraph script is neat, but nobody can be expected to have in-depth knowledge of every language they’re attempting to address at first blush. The initial graphs this produced for me were limited, and didn’t list all of the function calls. I found that the regular expressions callGraph uses to recognize function definitions can be extended with optional non-reference generating atoms. In this case, it was missing an understanding of javascript async functions, so I did a quick fork and pull request to insert
...(?:async\s+)?...
The behavior of import to me at the moment, concerning configuring jekyll and the jekyll build environment, are two github actions. They’re described in the file .github/workflows/pages.yml as such:
- name: Setup Pages
uses: actions/configure-pages@v2
- name: Build with Jekyll
uses: actions/jekyll-build-pages@v1
with:
source: ./
destination: ./_site
AFAICT, the action for deploy-github-pages specifically wants to interact with the github API in order to push to github pages. I specifically don’t want that, because I want to develop and test locally (or at least in a fashion which can be adapted besides github’s environment). If I understand correctly, there may be a way to configure that action to deploy to other providers, like Azure, but the documentation is sparse.
act for local development of the siteact can be installed in both manjaro and macOS from their package
management. In manjaro, the default-installed tool pacman will work to pull
from the AUR. In macOS, brew will do the trick. Docker is a dependency.
Blog -> weblog, in this case, build log
I will soon add this site as an entry to my homelab projects document. My plan is to do writeups of each of those projects in some amount of detail, and though I may or may not do those in their own posts or as part of the blogging function of jekyll, since this website is an active project, it makes perfect sense to blog as I go.