From 5195a358287cf916f3d46612cb266a0a3d36ee85 Mon Sep 17 00:00:00 2001 From: ktyl Date: Tue, 27 Sep 2022 00:42:05 +0100 Subject: [PATCH] add drone ci --- drone-ci.md | 71 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 71 insertions(+) create mode 100644 drone-ci.md diff --git a/drone-ci.md b/drone-ci.md new file mode 100644 index 0000000..9ca862d --- /dev/null +++ b/drone-ci.md @@ -0,0 +1,71 @@ +# Drone CI + +When it comes to automation, [GitLab CI](https://gitlab.com) 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](https://drone.io/) 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](gitea.io) instance to host the source. +You can find out about configuring Drone with Gitea [here](https://docs.drone.io/server/provider/gitea/). + + +## 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. + +```yml +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](https://docs.drone.io/secret/repository/) 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 +``` + +## Templates + +## References + +* [GitLab CI config to deploy via SSH](https://medium.com/@hfally/a-gitlab-ci-config-to-deploy-to-your-server-via-ssh-43bf3cf93775) +