3.3 KiB
Drone CI
When it comes to automation, GitLab CI has been my go-to for running builds, tests and deployments of projects from static websites to 3D open-world games. This has generally been on a self-hosted installation, and often makes use of physical runners. However, I have some gripes: I mostly only use it for the CI, but it comes with an issue tracker and Git hosting solution too - great for some cases, but overkill in so many others. Because it's such a complete solution, GitLab is a bit of a resource hog, and can often run frustratingly slowly.
Recently I've been playing with a friend's self-hosted instance of Drone CI as a lightweight alternative, and I much prefer it. I didn't set up the instance, so that part is out of scope for this post, but in case it's relevant, we're using a self-hosted Gitea instance to host the source. You can find out about configuring Drone with Gitea here.
Yet Another Yaml Config
Like GitLab, Drone is configured via a YAML file at the project root, called .drone.yml.
Drone is configured by creating 'steps' to the pipeline, where GitLab uses 'jobs'.
My first project's automation requirements were small - all I needed for a deployment was to copy all the files in a directory on every push to the main branch.
This means I needed secure access to the host, and the ability to copy files to it.
I didn't want to dedicate any permanent resources to such a small project, so opted for the docker pipeline option.
My pipeline would contain a single deploy step which would configure SSH access to the host, and then use it to copy the relevant files from the checked out version of the project.
I decided to use ubuntu as the Docker image for familiarity and accessibility - there are probably better options.
Drone widely supports Docker image registries; I have not used Docker much, but would like to get more experience with it.
kind: pipeline
type: docker
name: deploy
steps:
- name: deploy
image: ubuntu
when:
branch:
- main
commands:
- echo hello world
Secrets
A hugely important aspect of automation is ensuring the security of one's pipelines. Automated access between pipelines is a big risk, and should be locked down as much as possible. For passing around secrets such as passwords and SSH keys, Drone has a concept of secrets. I created a private key on my local machine for the runner's access to the remote host, and added a per-repository secret to contain the value. This is a named string value which can be accessed from within the context of a single pipeline step.
I also created secrets to contain values for the remote host address and the user to login as. These are less of a security concern than the private SSH key, but we should obfuscate them anyway. It's also a useful step towards generalising the pipeline for other projects, which we'll get into later.
This block was placed in the same step definition as above, below the image: entry:
environment:
HOST:
from_secret: host
USER:
from_secret: user
SSH_KEY:
from_secret: ssh_key