Skip to content

Add support for config-only platform properties

Before raising this MR, consider whether the following are required, and complete if so:

  • Unit tests
  • Metrics (not relevant)
  • Documentation update(s)

If not required, please explain in brief why not.

Description

Some platform properties don't make sense for matching, since they're intended to communicate some information to the worker about how to run the Action, rather than to determine which workers are able to run an Action. For example, a platform property for a docker image name or a chroot digest doesn't make sense for matching.

Currently, all properties are used in the matching. Taking the chroot example, this means that workers who need a chroot digest (for example) need to have all the possible values for that property specified on the command line for the worker. This is not ideal and also means that workers need to be restarted or redeployed whenever a new chroot is needed.

This MR allows properties to be specified as matching or config in the Execution service's configuration. config properties are not included in the set of properties used to match Jobs to workers. However, since they're part of the Command message, they still get passed through to the worker, so can still be used to pass information (such as a chroot digest).

Properties which don't specify a type are always treated as matching, to remain backwards compatible.

Validation

Deploy a BuildGrid server with a config-only property (you could add a property to data/config/default.conf and then run tox -e server).

Attach a worker to it which doesn't specify this property (simply doing tox -e bot -- host-tools will do this).

Run a test job which sets the config-only property, for example,

tox -e venv -- bgd execute command -p chrootDigest imaginary buildgrid ls

The job should be executed, despite no workers matching the property.

Issues addressed

Closes #333 (closed)

Merge request reports