A few months ago when I started working on this, I knew ZERO about any of this CI stuff. Now I have a pretty firm grasp on how everything fits together. And while this may not be your use case, it was educational for me to show my own. Not only did it force me to take another long look at my setup, build and pipeline, but it also gave me a reason to get a better understanding of each little piece of code that I wrote along the way. This all really helped put it together in order to write out descriptions of just how I made it work in the first place.
Now, I’m not going to claim that this is the best way (or even a good way) to go about setting up your CI, but it currently works for me. Through the process of documentation, I’m seeing a few places where I can optimize my own pipelines and make things a little more efficient. It’s an ever-changing process that you can tweak as long as you want, until you get something that you’re happy with. In my case, right now it works and does what I set out to do with it.
In future projects, I’m sure that a new pipeline would look a lot different. The nice thing about CI in general is that you can tailor it to your project and fine-tune the steps as necessary. In fact, using a simple pipeline template, you can throw this in your
.drone.yml file and be off and running:
kind: pipeline name: default steps: - name: frontend image: nginx commands: - echo hello world
Granted, that isn’t going to do much for you (other than getting rid of the CI nag in Github), but it is a base to build on.
Since starting this project/writeup, I’ve begun to plop other Drone configs in existing projects, and begun to write specifically for those. Through some trial and error, getting up and running with a project is surprisingly not difficult as it always seemed in the past.
For instance, I run a VM with Home Assistant to control some of the smart devices in my house:
kind: pipeline name: Home Assistant steps: - name: ha-ci image: python commands: - mv config/.drone_secrets.yaml config/secrets.yaml - pip3 install homeassistant - hass -c config --script check_config
I won’t get into my specific HA setup, but I did make a Drone pipeline (that runs a python image) that runs a HASS configuration check, which makes sure that my yaml syntax is setup correctly. Quite helpful in case a typo or extra space gets thrown in a configuration file. I don’t want that to be the cause of everything in my house ceasing to function.
The basics of this pipeline are:
- Clone the Github repo
- Move my placeholder
secrets.yamlfor format checking (This isn’t the real
secrets.yamlfile, as I don’t commit that to the repo, for obvious reasons)
- Run the python image and install Home Assistant with
- Run the Home Assistant config checker on the
configdirectory – to make sure that everything is cool with my setup
Another new project that I’m working on that I’ve recently started hooking up to a CI pipeline is my Tilde repo. This is a personal startpage that I’ll eventually use to replace my current one, once I get it dialed in a bit more. The Tilde project uses the volume cache image that I used previously on this site to cache the node modules that
yarn manages, and
gulp to process the site that I’m building. Since I’m still in development, notice that I’m only using it to check the
site-structure branches right now. I will definitely expand on this pipeline as I go along, as this one is evolving as I work on it.
kind: pipeline name: Tilde (redux) steps: - name: restore the cache image: drillster/drone-volume-cache volumes: - name: cache path: /cache settings: restore: true mount: - ./node_modules - name: yarn + gulp image: node:latest when: event: - push branch: - dev - site-structure commands: - yarn install - yarn global add gulp && gulp build - name: rebuild the cache image: drillster/drone-volume-cache volumes: - name: cache path: /cache settings: rebuild: true mount: - ./node_modules volumes: - name: cache host: path: /tmp/cache
Note that the pipelines above are definitely not the same use case as my pipeline setup for this site. I’m not doing any deploying or moving files onto other servers, I’m mostly doing installs to run/check/build versus a complete site solution.
As someone that didn’t know a single thing about CI (past what I had hacked together in the past), this whole process has been both helpful and eye-opening. It’s really changed that way that I think about the structure of my repo(s), how I setup configuration files and how I want a site to behave.
One of the most helpful quotes that I ran across during this process was from a snarky remark on the Drone discourse, but it helps put the whole thing in prespective:
If it doesn’t run (locally) on the command line, it’s not gonna work in the CI. Get it working on your machine first.
CI is really just setting up your project from scratch in a virtual machine. Once you get that, it really helps to wrap your head around the whole point of why you’re doing the things that you’re doing in any given pipeline. So, thanks for that, smart ass. You probably didn’t mean to, but you actually DID help me out with your shitty comment, even if it wasn’t from a question that I had anything to do with.