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
one 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 .gitlab-ci.yml
. However
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.