There are several tools that can help with CI/CD. These run as their own web services, which work with many source code management (SCM) systems to perform these tasks automatically. Drone is one such solution, that provides a way of executing pipelines — sets of steps that the service will run through such as building the software and running tests — that are described in the code itself. Drone is a flexible CI/CD tool that can perform this on many different types of runners, containers or machines where the project can be repeatably built.
This tutorial aims to show how Drone can integrate with the source code management tool Gitea in order to offer fully self-hosted solutions for SCM and CI/CD. You will be installing Drone, connecting it with Gitea, and creating a test project to see how the two services work together.
In order to complete this tutorial, you will need the following:
+<^>your_domain<^> in examples throughout.The first step to integrating Drone with Gitea — before even installing Drone itself — is to create an OAuth2 application in Gitea. OAuth2 is a way for one service provider to delegate access to another. For instance, you may want to be able to share information on one site without creating an entirely new account there when you already have an account elsewhere with that information. If both sites work with OAuth2, then you can authorize the first site to have access to that information on the second site. In this case, Drone, as an OAuth2 client of Gitea, will be granted access to information such as repositories and pull requests that it will need to run its CI/CD tasks.
+OAuth2 works by creating a client ID by which a client (Drone, in this case) identifies itself and a client secret by which it authenticates itself. Gitea will generate these values for you to provide to Drone when starting it.
+To generate the ID and secret, log in to your Gitea instance and click on your icon in the upper right corner to select Settings from the drop down menu. In that page, you will see a row of tabs along the top. Click Applications, and you’ll be presented with a screen allowing you to create OAuth2 Applications.
+Enter Drone CI or similar as your application name. For the redirect URI, enter the domain you have chosen for your Drone instance. This should take the form of https://<^>your_domain<^>/login — it’s important that the protocol (HTTPS, in this case) and domain name match exactly, and that you include the /login path at the end of the URL.
When you click Create Application, you will be presented with a screen showing the information that you just entered along with the OAuth2 client ID and client secret. Copy these both into a temporary document now, as they’ll be hidden as soon as you navigate away from the page. If you do lose them, note the Regenerate Secret link, which will allow you to create a new secret that you can use for your Drone installation.
+Now that you have your OAuth2 application created in Gitea, you can begin installing Drone. For this section, you will need the client ID and secret created in Step 1, the domain names for your Gitea instance and Drone instance, and an RPC secret. For this example, we will be using sammy-says.
On the server you created in the prerequisites, log in as your user and create a new directory named drone and move into it:
mkdir drone
+cd drone
+Now, create a new file named docker-compose.yml using your preferred text editor. The following example uses nano. This file will contain the descriptions of the containers that will run as part of your Drone installation:
nano docker-compose.yml
+Add the following into this new file, changing the highlighted values as required:
+version: "3"
+
+networks:
+ drone:
+ external: false
+
+services:
+ server:
+ image: drone/drone:2
+ container_name: server
+ environment:
+ - DRONE_GITEA_SERVER=https://<^>your_gitea_domain<^>
+ - DRONE_GITEA_CLIENT_ID=<^>gitea_client_ID<^>
+ - DRONE_GITEA_CLIENT_SECRET=<^>gitea_client_secret<^>
+ - DRONE_RPC_SECRET=<^>sammy-says<^>
+ - DRONE_SERVER_HOST=<^>your_drone_domain<^>
+ - DRONE_SERVER_PROTO=https
+ - DRONE_TLS_AUTOCERT=true
+ networks:
+ - drone
+ volumes:
+ - ./drone:/data
+ ports:
+ - "80:80"
+ - "443:443"
+ runner:
+ image: drone/drone-runner-docker:1
+ container_name: runner
+ environment:
+ - DRONE_RPC_PROTO=https
+ - DRONE_RPC_HOST=<^>your_drone_domain<^>
+ - DRONE_RPC_SECRET=<^>sammy-says<^>
+ - DRONE_RUNNER_CAPACITY=2
+ - DRONE_RUNNER_NAME=gitea-runner
+ networks:
+ - drone
+ volumes:
+ - /var/run/docker.sock:/var/run/docker.sock
+ ports:
+ - "3000:3000"
+Let’s walk through what this file does:
+version: "3": this lets Docker Compose know what version of configuration file this is.networks: this section declares the networking setup of our collection of containers. In this case a drone network is created, but is not exposed.services: for each of the containers that we have, we set up environment variables available to the service, assign volumes for data that’s stored on the host, and expose various ports. Here are our services:server: this service uses the drone/drone:2 image, meaning that it runs the drone server itself. The environment variables passed in provide the service with information such as how to connect to and authorize with Gitea, a secret for the remote procedure calls (RPC), and with DRONE_TLS_AUTOCERT, we let the drone server provision a SSL certificate using Let’s Encrypt. The container exposes port 80 for HTTP and port 443 for HTTPS. The local directory drone will be mapped to the container’s /data directory, allowing all of Drone’s information to be stored locally, meaning that it can be backed up and persist across containers.runner: this service uses the drone/drone-runner-docker:1 image, meaning that it will be in control of provisioning Docker containers for running tests on your code. This runner is what connects to the server container using RPC over port 3000 to start runs and report on the results. Because of this, /var/run/docker.sock is mapped as a volume. This special file is the means by which the runner process can communicate with Docker to start these containers.<$>[note] +Note: There are several different types of runners for Drone, each of which provides different benefits. Docker runners are good for ephemeral actions such as running tests, as they are cleaned up after the run completes and they do not persist any data. If you need the ability to persist data — deploy your service, for instance — you will need to use a different runner such as the Exec Runner or DigitalOcean runner. For more information on the available runners and the reasons for using them, the Drone Runner Documentation has instructions for each. +<$>
+Now that your Docker Compose file is complete, save and close it. If you used nano to edit the file, you can do so by pressing CTRL + X, Y, and ENTER.
With this file in place you can then bring the containers up using Docker Compose:
+docker-compose up
+This command will pull down the images, start the server and runner containers, and will return output like this:
+[+] Running 5/5
+ ⠿ server Pulled
+ ⠿ 79e9f2f55bf5 Pull complete
+ ⠿ 3534e21ebea8 Pull complete
+ ⠿ 2f27386bf47c Pull complete
+ ⠿ 631cac189eb7 Pull complete
+[+] Running 2/2
+ ⠿ Network drone_drone Created
+ ⠿ Container server Created
+Attaching to server
+server | {"acme":true,"host":"mscottclary-drone.do-community.com","level":"info","msg":"starting the http server","port":":443","proto":"https","time":"2022-06-29T21:01:12Z","url":"https://mscottclary-drone.do-community.com"}
+server | {"interval":"30m0s","level":"info","msg":"starting the cron scheduler","time":"2022-06-29T21:01:12Z"}
+server | {"interval":"24h0m0s","level":"info","msg":"starting the zombie build reaper","time":"2022-06-29T21:01:12Z"}
+Give this a few minutes to finish running the Let’s Encrypt certificate provisioning.
+This will leave the container running in the foreground, however, and it will stop as soon as you exit the process with Ctrl + C or by losing your connection. In order to have the container run in the background as a separate process, you can append the -d flag to the Compose command:
docker-compose up -d
+You will be notified when the container starts and then returned to your shell.
+Now that Drone is up and running, you can connect it to Gitea to authorize runs via OAuth2. Visit your Drone URL in your browser, where you will see a message that says “You will be redirected to your source control management system to authenticate” above a Continue button. If all of the information that has been entered to now has been valid, you will find yourself on a Gitea page asking for your authorization to give Drone permissions.
+<$>[note]
+Note: If you run into an error saying that a client ID or redirect URL was not recognized, check the values entered in your docker-compose.yml to ensure they match your domain names and Gitea OAuth2 information exactly. When you are sure, running docker-compose restart will bring the containers back up with the correct information.
+<$>
Once you grant permission, you will be returned to your Drone dashboard, where you will see a list of your repositories.
+