Recipes

CIVET recipes describe what happens when a git event occurs. For example, when a pull request for a repository is reported to CIVET, it looks through its recipes for matching repositories and matching build_users.

All recipes are kept in a repository. Whenever changes to the repository occur the load_recipes command needs to be run.

./manage.py load_recipes

This converts the *.cfg files into an internal database representation. The SHA of the recipes repository is recorded so that, in theory, one could go back to a specific SHA of the recipe repository to reproduce a test.

See civet_example_recipes for some sample recipes and scripts.

Adding/Changing recipes

Recipes live in the recipes directory at the top level of the recipe repository. Adding a new recipe is just adding a new file to the recipe repository. Whether adding/removing/changing a recipe, you should commit your changes then you will need to run the load_recipes command again for the CIVET server to pick it up.

Scripts

The scripts that are used in the recipes typically live in the scripts directory at the top level of the repository but this is not required. All the script names and dependencies in a recipe file are relative to the top of the recipes repository.

Jobs

After the load_recipes is executed an internal representation of the recipe file is created in the database. When an event from the git server happens (like a pull request event), it checks the database for recipes matching the event. It then turns the recipe into one or more jobs. It can be more than one job if there are multiple build_configs specified. This can be used to run the same recipe in different configurations. For example, you might have build_configs = linux-clang,linux-gcc. So this recipe would create two jobs, one for linux-gcc and another for linux-clang. On the client side you would configure each of these configurations to use a different compiler.