Integrations, code, and the oxford comma

Part Six: Wrapping it all up + What I learned along the way

Note:

This is Part Six, in a multi-part series.
Here are the other parts that you should probably check out as well:

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.

Extensibility

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.

HASS

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 .drone_secrets.yaml to secrets.yaml for format checking (This isn’t the real secrets.yaml file, as I don’t commit that to the repo, for obvious reasons)
  • Run the python image and install Home Assistant with pip3
  • Run the Home Assistant config checker on the config directory – to make sure that everything is cool with my setup

Tilde (redux)

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 dev and 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

Wrapping up

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.