What is Herald

Herald is a Drupal-powered task runner. It's main purpose is to serve as a QA system, or even a CI server. It is different from other systems like Jenkins or Gitlab CI in that it focuses solely on Drupal projects and code. It's goal is to become a QA system for teams, to make sure they ship quality code. Although it's original purpose was not to serve as a CI server per-se (meaning, actually deploying code to servers on successful builds), it is fully capable of doing so.

How does Herald work

At its core, Herald is a very simple, but flexible and powerful system. It comes with a flexible API which other modules can extend to provide new build methods and tasks. In fact, Herald Core does not provide any functionality other than the API and underlying structure. This keeps it robust and lean from the ground up. It ships with several submodules, however, which each provide a very specific functionality. For instance, it ships with task runners for checking Drupal coding standards, CSS syntax (using the D8 standard), JS syntax and running Simpletests. It ships with build systems for Drupal.org repositories (which will fetch code on specified intervals) or private Git repositories (which exposes a Webhook to react on pushes).


To start, we create projects. A project can be a module, a theme, or even a distribution (not implemented yet). This project has several settings, such as Core version, which tasks to run on it, and how new builds are created. A project on itself does nothing more than provide information to other parts of the system. Check the projects page for some examples.


Builds are created for projects on certain events. These events can vary (cron runs, URL callbacks, etc), and a project can react on only one, or multiple events. Whenever a build is created, tasks are automatically registered and queued for execution. Each build puts the project code somewhere on the server, and notifies other parts of the system where it is located. This allows task runners to fetch the code and perform actions on it (like syntax checking).


Tasks are created for builds, as soon as a new build is created ("registered"). A task is queued for execution on its creation. Tasks are run on Cron runs, which makes it very important to schedule crons regularly. Using a system like Elysia Cron is highly recommended, so crons can run very frequently (this site runs cron every minute), while running heavy jobs (like cache clearing) less often (like once a day). Tasks can be configured by type, and we can limit the number of concurrent tasks. For example, we can run 10 CSSLint jobs concurrently without any problem, but probably want to limit the Simpletest runs to only 1.

Help needed

Herald is still in its very early stages of development. Teams might want to start using it internally, but I would not recommend using it on a public server. If you are interested in Herald, please contribute to the project, give feedback, or submit bug reports. If you have any questions, don't hesitate to contact me.