I'm using this post as a bit of a testing ground to see if my CI is working. Ideally, when I change files in src/
and push them up to master
the website should get built and deployed. In reality, we're about to find out what happens. I'll explain in a second...
Ah, now see, that didn't work. Not that I expected it to, but still. Let me explain what I have set up so far, then we'll get this fixed. I've got my site running on a basic Debian server somewhere in the ether. It's served with Caddy. The website repo is hosted on GitHub and there's a workflow to build it then copy it over to the server.
The website is bundled with Parcel. If you check the package.json
, you can see Parcel will bundle, optimize, etc the source files and spit everything out into a new dist/
directory. The files in dist/
need to be copied over to the directory they're served from on the server. We'll use rsync to do that.
The server has a github
user. It's not allowed to log in, it doesn't have a shell, it's basically only there to receive files from our Github Action. In fact, that's the only command that will run whenever the github
user connects. The Github user has an authorized SSH key stored as a secret in the Github repo. Command restriction is accomplished with the really neat rrsync
script that comes bundled with rsync.
The reason why that first attempt didn't work was a little tricky. SSH connections validate a server's fingerprint when you first connect. If you check the Action, I copy both the private key and the known_hosts
file to the runner's .ssh
directory. Well-what-had-happened-was that key was coped incorrectly in my repository secrets. Let me update that and try this again...
And there we have it! I grabbed the proper host key with ssh-keyscan justintout.com
and updated the secret. Now, whenever I push changes in src/
to master
, they'll automatically get built and deployed to my server.
For a more "tutorial-ey" walk-through of the process, I wrote this Gist. Check it out if you're interested in setting something similar up. Honestly, hosting a github.io site is probably easier, but I think this is a super worthwhile exercise.