Question

Caution

Buildbot no longer supports Python 2.7 on the Buildbot master.

2.5.7. Builder Configuration

• When more than one build request is available for a builder, Buildbot can “collapse” the requests into a single build. This is desirable when build requests arrive more quickly than the available workers can satisfy them, but has the drawback that separate results for each build are not available.

  Requests are only candidated for a merge if both requests have exactly the same codebases.

  This behavior can be controlled globally, using the collapseRequests parameter, and on a per-Builder basis, using the collapseRequests argument to the Builder configuration. If collapseRequests is given, it completely overrides the global configuration.

  Possible values for both collapseRequests configurations are:

  True

  Requests will be collapsed if their sourcestamp are compatible (see below for definition of compatible).

  False

  Requests will never be collapsed.

  callable(builder, req1, req2)

  Requests will be collapsed if the callable returns true. See Collapse Request Functions for detailed example.

  Sourcestamps are compatible if all of the below conditions are met:

  • Their codebase, branch, project, and repository attributes match exactly

  • Neither source stamp has a patch (e.g., from a try scheduler)

  • Either both source stamps are associated with changes, or neither is associated with changes but they have matching revisions.

  The BuilderConfig parameter nextBuild can be used to prioritize build requests within a builder. Note that this is orthogonal to Prioritizing Builders, which controls the order in which builders are called on to start their builds. The details of writing such a function are in Build Priority Functions.

  Such a function can be provided to the BuilderConfig as follows:

  def pickNextBuild(builder, requests):
      ...
  c['builders'] = [
      BuilderConfig(name='test', factory=f,
          nextBuild=pickNextBuild,
          workernames=['worker1', 'worker2', 'worker3', 'worker4']),
  ]
  

  Dynamic Trigger is a method which allows to trigger the same builder, with different parameters. This method is used by frameworks which store the build config along side the source code like Buildbot_travis. The drawback of this method is that it is difficult to extract statistics for similar builds. The standard dashboards are not working well due to the fact that all the builds are on the same builder.

  In order to overcome these drawbacks, Buildbot has the concept of virtual builder. If a build has the property virtual_builder_name, it will automatically attach to that builder instead of the original builder. That created virtual builder is not attached to any master and is only used for better sorting in the UI and better statistics. The original builder and worker configuration is still used for all other build behaviors.

  The virtual builder metadata is configured with the following properties:

  • virtual_builder_name: The name of the virtual builder.

  • virtual_builder_description: The description of the virtual builder.

  • virtual_builder_project: The project of the virtual builder.

  • virtual_builder_tags: The tags for the virtual builder.

  You can also use virtual builders with SingleBranchScheduler. For example if you want to automatically build all branches in your project without having to manually create a new builder each time one is added:

  c['schedulers'].append(schedulers.SingleBranchScheduler(
      name='myproject-epics',
      change_filter=util.ChangeFilter(branch_re='epics/.*'),
      builderNames=['myproject-epics'],
      properties={
          'virtual_builder_name': util.Interpolate("myproject-%(ss::branch)s")
      }
  ))