Drone is a continuous integration framework similar to Travis CI. The C++ Alliance is offering a hosted Drone server for Boost libraries.
The motivation for setting up an internal CI system is that travis-ci.org builds have become slow, and they have announced the imminent shutdown of the website. An extensive review of self-hosted options was conducted, including many Continuous Integration services from https://github.com/ligurio/awesome-ci . Drone was chosen because it provides a feature set similar to Travis, it's easy to use, fully featured, free, open source, and it seems to be well designed and well supported. Drone permits self-hosting. Dedicated servers can be built and scaled out as needed.
The C++ Alliance is not proposing that Drone should be the only alternative for Boost libraries, but rather that having multiple active CI systems provides better redundancy and more test coverage.
Another set of pull requests were sent which converted .travis.yml to a Github Actions config.
To find a copy of the most up-to-date github actions or drone config file, check boost-ci.
If you are a Boost author, follow these steps to get started.
- Visit https://drone.cpp.al
- "Authorize Drone". Click the "Authorize cppalliance-drone" button.
- Sync repositories. Click the "sync" button.
- A list of repositories will appear. For each repo, click and then choose "Activate Repository".
- In the settings page, change Configuration from .drone.yml to .drone.star. "Save".
The drone files must be present in the target branch, so merge .drone.star into "develop" if you have not already done so.
Push a new commit or submit a pull request to trigger a build in drone.
The .drone.star file uses the starlark language. Starlark’s syntax is inspired by (and nearly identical to) Python3. This allows great flexibility when creating a config file.
The hosted instance of Drone at https://drone.cpp.al has an access filter permitting any boostorg github repository. If you would like to add a fork under a different account name, please contact us.
-
"What are the files with the funny hex numbers?" These drone files were generated with an automated script based on travis.yml. The most common job configuration was detected and called "boost.sh". It's often the main script. For other configurations, if the "install" and "script" portions of the job varied, then they were named based on their sha1 hash value, such as .drone/840114c2a5-fda7c76df5.sh, with .drone.star using the "buildtype" field to reference it. You may optionally change these names to something more meaningful than a hash.
-
"In the drone.star file, what is DRONE_JOB_UUID?" This variable does not have any special meaning, but should be unique. The UUID's were initially generated by taking a SHA1 hash of the "job number", such as "1" or "2". You could literally use "1" or "2" if you preferred. The point is to have an identifier to distinguish the job so that in the other drone scripts you could conditionally run a step for only one of the jobs if the UUID matches.
-
asan jobs require privileged access, and will show an error about "LeakSanitizer does not work under ptrace". Add an argument "privileged=True" to linux_cxx() in the .drone.star file.
-
If one of the jobs shows an error about requiring privileged access in the Drone UI, contact an administrator to increase privileges for the docker container.
-
If you have any questions or problems, please open an Issue in this github repo.