Your submission was sent successfully! Close

  1. Blog
  2. Article

Charles Butler
on 15 July 2015

Continuous Integration with Juju and Drone CI


Delivering your Charms to the community can seem like an uphill climb when you have minimal and manual testing around your project. The ~charmer review process is pretty rigerous and as anyone who has run the Gauntlet to attain ~recommended status can attest, we really stress the service before approval. One of the ways to have your review expedited is by including a full suite of tests that deploy, configure, and stress the workload it is deploying.

A little known fact about Juju Charms, is each Charm is a software project. Often involving many developers from different focus groups, committing against different features. The fact you can write a prototype charm in about 20 minutes is a great byproduct of our language freedom – but when it comes to delivering a consistent high quality experience, you really need to adopt a delivery pipeline that rigerously tests your charm quality through fast running individual unit tests, but also you should be testing a full deployment scenario on the cloud.

I had a requirement of my CI Service being rapid to deploy, always configured for all my projects (so version controlled CI config like Travis-CI), hosted on premise so I can take my toys with me without worrying about data ownership, and be flexible enough for me to extend via an API.

Introducing Drone

Drone is a Continous Integration server written in GoLang by a team of dedicated individuals centered around this Open Source project. Its light weight, built on top of Docker to provide test isolation, and supports delivery of artifacts to several providers, as well as deployment options for Modern PAAS providers as well as git based delivery mechanisms.

It comes in 2 flavors, a hosted version over at as well as a deployable on premise edition, which will be covered in this post today.


In order to follow along, you will need to gather a few things.

  • Cloud Credentials for your Integration Server (per project preferrable)
  • A Juju environment
  • A charm with Unit Tests and Amulet tests

Standing up the CI Service

I’ll be keeping the versions of Drone published in lock step with all the tags present in the Github Repository.

juju deploy cs:~lazypower/drone

This charm will pull and configure the latest docker daemon, install the Drone-CI binaries, and expose the DroneCI service on port 80.

What you will be greeted with when loading the Drone application URL is a single button link to Documentation.

Configuring Authorization

Drone requires an Authorization Provider in order to ‘activate’ itself. Drone fully integrates with the API’s as a consumer leveraging the service you login from.

Setting up GitHub

Generate Client and Secret

You must register your application with GitHub in order to generate a Client and Secret. Navigate to your account settings and choose Applications from the menu, and click Register new application.

Please use /api/auth/ as the Authorization callback URL path.

Once you have your application configured in GitHub, set these API credentials on the charm

juju set drone github_client=XXX github_secret=XXX github_enabled=true

Config Helper

This is beta, has very little error checking, and may or may not work given the input you feed the script. Please use with caution. The charm ships with a script to assist in configuring jobs. This is best run locally

git clone drone
cd drone/scripts
./config -e {{environment}} -r {{repository https clone url}} -c {{charm name}}

You will receive output that is copy/pasteable to both the drone-ci repository configuration, and the .drone.yaml to be embedded in the git repository.

Run the config helper

Populate the project secrets

Populate .drone.yml in your repository

As an example, i’ll paste in some pseudo configuration. This is not 1:1, and I did give a stellar breakdown over the format of this job in the explainer video.

To investigate further on your own, consult the format doc for the .drone.yml in the upstream docs

image: jujusolutions/charmbox
    - JUJU_TEST_CHARM='{{charm}}'
    - JUJU_REPOSITORY='/var/cache/drone/src/{{provider}}/{{username}}/'
    path: {{provider}}
    - sudo apt-get update
    - juju init
    - echo $ENVYAML | base64 --decode > ~/.juju/environments.yaml
    - juju switch $CIENV
    - mkdir ../trusty
    - cd .. && mv {{repo}} trusty/{{charm}} && cd trusty/{{charm}}
    - bundletester -F -l DEBUG -v


Simply make a commit and enjoy the results of using the cloud to run integration suites of your project against the cloud provider configured.

Juju + Drone sitting in a tree 🙂


This is still very much beta quality in terms of exploration of what we can do here. As in, how do you white list contributors so only certain PRs / Master branch is run with a full integration suite, otherwise – only unit tests are run?

Matrix builds against multiple cloud providers (v0.4 pending, will enable this)

If you’ve got any feedback, questions, comments about this – I’m happy to talk with you about leveraging this setup for your own projects. You can find me in #system-zoo on, as well as #juju.

All issues found should be filed against the project on GitHub.

Related posts

Michael C. Jaeger
4 September 2023

Efficiency redefined: Discover the power of software operators during Operator Day, co-located at KubeCon North America 2023

Charms Article

The 7th Operator Day is a virtual event and will take place on the first day of the KubeCon week, Monday, 6 November 2023. The event is entirely virtual. You can dial in from anywhere and attend. You can register at the KubeCon NA 2023 conference or directly at the event page. ...

Michael C. Jaeger
22 June 2023

Adopting a low-ops approach with software operators

Charms Article

How enterprise DevOps teams can automate repetitive tasks while staying in control  Low-ops means minimising the effort for operating applications by automating as many tasks as possible. However, given the maximum automation, how can an SRE or DevOps engineer stay in control? Doesn’t automating tasks and being in control sound like a par ...

Andre Ruiz
17 May 2023

A brief history of MicroStack

Cloud and server OpenStack

OpenStack is no doubt a wonderful and successful piece of software. It allows you to create your own cloud infrastructure, and thanks to its open-source nature, it’s free to use for everyone. But as with many giant software projects, all that power comes with a challenge: it is reasonably complex to install and configure. A ...