Automation setup for cpp-ethereum

At the time of writing all of the automation for cpp-ethereum is driven using a Jenkins instance hosted at

There is a “pretty alias” to the setup at, but that is owned by Bob Summerwill personally, not by the Ethereum Foundation, and might end up pointing to something else at a later date.


It runs in parallel with the Ethereum buildbot instance which is used for Go and Python builds.

The fact that we have two different automation systems is not ideal, and is for historical reasons. It would make sense for us to consolidate all Ethereum Foundation projects into a single, consistent automation setup, but that is a non-trivial amount of work. We’re talking about that. It will be much easier to assess that when we have completed the repo reorg for the C++ codebase.

The current Jenkins setup is missing a canonical continuous integration target, which is a major weakness. There is no single URL which you can visit to find out whether the C++ builds are working or broken at HEAD. There is not even a URL which you can visit per repository, to find if the individual repositories are working or broken.

We are also missing automation for webthree-umbrella as a whole, to know whether the set of repositories which we are publishing is working or broken.

What we do have is automation of our pull-requests. Those are built against the develop branches of the repositories which they depend on. There is a mechanism for specifying alternative branches for those dependencies, when testing changes which span multiple repositories. But it is broken.

Here are the Jenkins projects for the PR automation. These are triggered automatically via Github webhooks whenever new PRs are created, or when the content of the branches for existing PRs is updated:

Here are the other Jenkins projects we have:

  • ethbinaries-develop and ethbinaries-release - Projects for generating Windows and OS X binaries for the develop and release branches of the webthree-umbrella. The develop project is run nightly at midnight, UTC. The release project is run manually.
  • ppa-build-develop and ppa-build-release - Projects for packaging source and build steps which are then pushing to Launchpad where they will be built, and the binaries pushed to the world if they are successful. The develop project is run nightly at midnight, UTC. The release project is run manually.
  • solidity-emscripten - Solidity builds for the Emscripten architecture. This is the build target, which calls the publish target detailed below. It is run nightly at midnight, UTC.
  • update-umbrella - Utility project which can be run manually to update the submodules in the webthree-umbrella project. It will soon be obsolete. It is run manually, and also nightly.

The following projects are effectively “libraries” which are used to build the “user-facing” projects above.

Bob does not know what these Jenkins targets are. They may be obsolete.

We have been making a conscious effort to move our automation scripts into Git from Jenkins to reduce the “voodoo factor” in our automation. It is still a work in progress, but here are some key scripts which our automation uses:

But we still have some scripts which are orphaned within Jenkins:

Setting up a new Jenkins slave

This is a nightmare process. Here’s how to add an OS X slave. The process for other platforms will vary, but we’ve not had to do it yet.

Known issues

  • Lack of canonical build
  • Lack of webthree-umbrella builds
  • No automated Windows tests
  • Broken cross-repo PRs
  • Hanging tests
  • Incomplete test suits
  • Do we run “ethereum/tests” at all?
  • Do we run “ethereum/rpc-tests” at all?
  • Windows box is running Windows 7 home edition. No RDC access.
  • Running Visual Studio 2013.
  • Should be running Windows 10 with VS2015 targeting Windows7
  • We still don’t have working El Capitan binaries
  • Nothing doing Homebrew/PPA updates per cycle
  • No clean builds ever?