Once you start putting your home dir in version control, some more options start coming up. And with something like a personal gitlab instance those options multiply even more. Here I’m going to explore using gitlab’s CI features.
I already discussed using gitlab’s ticketing feature to keep track of tasks. And previously I wrote about an update script for my home dir to keep the various tools I use current. However gitlab also offers a CI system which allows me to automate those updates.
The first step is to move that update script into a hook. Vcsh supports
hooks and you can have one run after a pull happens. I have mine set a
stamp file so that it only does the update once a day. This means that
vcsh pull will take a bit longer, but that’s fine. And because of
the next step it will generally only take a long time on one machine.
In fact, if I get around to scheduling the CI pipeline once a night,
it shouldn’t even take time then.
The next part of this is the configuration file for Gitlab’s CI.
Normally it’s at the base of the repo in
that won’t work well here because that would go in the base of my home
dir. I’m using my history repo to trigger ci builds so I put my
CI configs in
~/.config/vcsh/gitlab/past-ci.yml. It’s then
a simple matter of going to my history project in gitlab and setting a
custom path for the CI YAML file and adding an ssh private key to the
CI variables. The config is really simple - the YAML file:
And then the script:
In the future I’m probably going to explore something like renovate-bot for my home dir to keep scripts and third party scripts up to date. I use reminders that I wrote myself elsewhere, but this might be better if it can send me merge requests.