Integrations, code, and the oxford comma

Part Three: Setting up Drone for your project

Note:

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

Now that I’ve done a great job of distracting from the task at hand, I suppose that we should actually get into setting up CI for Drone on a project. Assuming that you already have a project setup in Github and you’re ready to test some builds, I’ll show some examples of how have have it setup to run this project currently.

Drone setup and configuration

Inside of each project you want to connect to Drone, you need a file called .drone.yml. This will house your build configuration and everything you want Drone to do for you. Assuming that you already have Drone setup on your server now (if not, go back to Part One and do that), and have connected it to your Github account, it’s time to make your project active.

Setting up the webhook

By default, your repositories (and others that you have access to from other accounts at Github) should show up in the list. All projects will appear with grey text and a link on the right that says ACTIVATE, when they’re inactive. Select your project from the list and click on the ACTIVATE button in the project to turn it on. Drone will add a webhook to your project on Github (github.com/USER/PROJECT/settings/hooks) that will let your repo talk to Drone.

Secrets and settings

Under the Settings tab on your project, you have the option to configure a few different things. Since I have a private repo, I left the visibility as Private, which was picked up when Drone scanned the repo initially. Everything else was left at the default settings. (For instance, if you don’t want a .drone.yml file in your repo, you can change the name of the file that Drone looks for. The default was fine for me, but I’m sure it’s necessary for other use-cases.)

Since we’re using Drone to connect to AWS and then SSH into our server, we need to let Drone know what our access keys are so it can connect. Since we don’t want to make the mistake of accidentally putting usernames and passwords into our pipeline in the clear, we’ll pass along some Drone variables later to access these keys. It’s pretty easy, as you just need to put the name of your secret into the Secret Name and your key value into the Secret Value fields and click the Add a Secret button. For example, I have several keys in for usernames/passwords in my Drone config now:

Secret Name
aws_access_key_id
aws_secret_access_key
ssh_deploy_key
ssh_password

Of note: once you add a secret, there is no way to view the contents of that secret again. If you lose your secret value or need to change it, you’ll have to hit the DELETE button on an existing secret and recreate it. Not hard, but it can get annoying if you’re careless.

Trusted repositories

One of the other options that is available (and doesn’t show up unless you’re logged in as an admin) is the Trusted checkbox. Only use this if you know what you’re doing.

Since I’m mounting volumes in my Docker containers via Drone pipelines, this needs to be ON.

This setting will show up in your project settings, next to the Protected checkbox. If you don’t see it, there’s a few things that you’ll need to edit in order to make it show up in the UI.

Assuming that when you originally setup Drone and logged in for the first time, you were prompted to create a user account. You’ll want to use that same user account and recreate your Docker image with the added environmental variable:

--env=DRONE_USER_CREATE=username:YOURUSERNAME,admin:true

You can do this via Portainer if you have that installed. In order to do it there, open the Portainer admin dashboard, and navigate to your container. The easiest way to accomplish adding the env var is to hit the Stop button for your container, then click on the Duplicate/Edit button. On the bottom, there will be a list of tabs to choose from. You want to click on ENV, where you should see all of your existing environmental variables populated. Click on the add environment variable button to add the following vars:

name value
DRONE_USER_CREATE username:YOURUSERNAME,admin:true

Once you add this, go ahead and hit the Deploy the Container button. You’ll probably be prompted with the “ARE YOU SURE? A container with the same name already exists. Portainer can automatically remove it and re-create one. Do you want to replace it?” message, which is fine to say yes to unless you have a specific reason believe otherwise. Your container should relaunch with the ability to toggle the checkbox on the Trusted box now.

Continued in Part Four »