3.8 Build Properties

Each build has a set of “Build Properties”, which can be used by its BuildSteps to modify their actions. These properties, in the form of key-value pairs, provide a general framework for dynamically altering the behavior of a build based on its circumstances.

Properties come from a number of places:

• global configuration – These properties apply to all builds.
• schedulers – A scheduler can specify properties available to all the builds it starts.
• changes – A change can have properties attached to it. These are usually specified through a change source (see Change Sources), the "Force Build" form on the web interface (see WebStatus), or sendchange (see sendchange).
• buildslaves – A buildslave can pass properties on to the builds it performs.
• builds – A build automatically sets a number of properties on itself.
• builders – A builder can set properties on all the builds it runs.
• steps – The steps of a build can set properties that are available to subsequent steps. In particular, source steps set a number of properties.

Properties are very flexible, and can be used to implement all manner of functionality. Here are some examples:

Most Source steps record the revision that they checked out in the got_revision property. A later step could use this property to specify the name of a fully-built tarball, dropped in an easily-acessible directory for later testing.

Some projects want to perform nightly builds as well as bulding in response to committed changes. Such a project would run two schedulers, both pointing to the same set of builders, but could provide an is_nightly property so that steps can distinguish the nightly builds, perhaps to run more resource-intensive tests.

Some projects have different build processes on different systems. Rather than create a build factory for each slave, the steps can use buildslave properties to identify the unique aspects of each slave and adapt the build process dynamically.