Any attributes not in compare_attrs will not be considered when comparing objects.
This is used to implement Buildbot’s reconfig logic, where a comparison between the new and existing objects is used to determine whether the new object should replace the existing object.
If the comparison shows the objects to be equivalent, then the old object is left in place.
If they differ, the old object is removed from the buildmaster and the new object added.

For use in configuration objects (schedulers, changesources, etc.), include any attributes which are set in the constructor based on the user’s configuration.
Be sure to also include the superclass’s list, e.g.:

A point to note is that the compare_attrs list is cumulative; that is, when a subclass also has a compare_attrs and the parent class has a compare_attrs, the subclass’ compare_attrs also includes the parent class’ compare_attrs.

This class also implements the buildbot.interfaces.IConfigured interface.
The configuration is automatically generated, being the dict of all compare_attrs.

This function will filter out some inappropriate characters for filenames; it is suitable for adapting strings from the configuration for use as filenames.
It is not suitable for use with strings from untrusted sources.

A datetime.tzinfo subclass representing UTC time.
A similar class has finally been added to Python in version 3.2, but the implementation is simple enough to include here.
This is mostly used in tests to create timezone-aware datetime objects in UTC:

This function is intended to support the many places in Buildbot where the user can specify either a string or a list of strings, but the implementation wishes to always consider lists.
It converts any string to a single-element list, None to an empty list, and any iterable to a list.
Input lists are copied, avoiding aliasing issues.

This is a sentinel value used to indicate that no branch is specified.
It is necessary since schedulers and change sources consider None a valid name for a branch.
This is generally used as a default value in a method signature, and then tested against with is:

This decorator will cause the wrapped function to be run in the Twisted reactor, with the reactor stopped when the function completes.
It returns the result of the wrapped function.
If the wrapped function fails, its traceback will be printed, the reactor halted, and None returned.

This function is intended to help various components to parse git urls.
It helps to find the <owner>/<repo> of a git repository url coming from a change, in order to call urls.
owner and repo is a common scheme for identifying git repository between various git hosting services like GitHub, GitLab, BitBucket, etc.
Each service have their own naming for similar things, but we choose to use the GitHub naming as a de-facto standard.
To simplify implementation, the parser is accepting invalid urls, but it should always parse valid urls correctly.
The unit tests in test_util_giturlparse.py is the references of what the parser is accepting.
Please feel free to update the parser and unit tests

miss_fn – function to call, with key as parameter, for cache misses.
The function should return the value associated with the key argument, or None if there is no value associated with the key.

max_size – maximum number of objects in the cache.

This is a simple least-recently-used cache.
When the cache grows beyond the maximum size, the least-recently used items will be automatically removed from the cache.

This cache is designed to control memory usage by minimizing duplication of objects, while avoiding unnecessary re-fetching of the same rows from the database.

All values are also stored in a weak valued dictionary, even after they have expired from the cache.
This allows values that are used elsewhere in Buildbot to “stick” in the cache in case they are needed by another component.
Weak references cannot be used for some types, so these types are not compatible with this class.
Note that dictionaries can be weakly referenced if they are an instance of a subclass of dict.

If the result of the miss_fn is None, then the value is not cached; this is intended to avoid caching negative results.

Fetch a value from the cache by key, invoking miss_fn(key,**miss_fn_kwargs) if the key is not in the cache.

Any additional keyword arguments are passed to the miss_fn as keyword arguments; these can supply additional information relating to the key.
It is up to the caller to ensure that this information is functionally identical for each key value: if the key is already in the cache, the miss_fn will not be invoked, even if the keyword arguments differ.

Check invariants on the cache.
This is intended for debugging purposes.

AsyncLRUCache(miss_fn, max_size=50):

Parameters:

miss_fn – This is the same as the miss_fn for class LRUCache, with the difference that this function must return a Deferred.

max_size – maximum number of objects in the cache.

This class has the same functional interface as LRUCache, but asynchronous locking is used to ensure that in the common case of multiple concurrent requests for the same key, only one fetch is performed.

This is a clone of the Python collections.defaultdict for use in Python-2.4.
In later versions, this is simply a reference to the built-in defaultdict, so Buildbot code can simply use buildbot.util.collections.defaultdict everywhere.

This function returns a Deferred which will fire in a later reactor turn, after the current call stack has been completed, and after all other Deferreds previously scheduled with eventually.
The returned Deferred will never fail.

It’s often necessary to perform some action in response to a particular type of event.
For example, steps need to update their status after updates arrive from the worker.
However, when many events arrive in quick succession, it’s more efficient to only perform the action once, after the last event has occurred.

get_reactor – A callable that takes the underlying instance and returns the reactor to use. Defaults to instance.master.reactor.

Returns a decorator that debounces the underlying method.
The underlying method must take no arguments (except self).

For each call to the decorated method, the underlying method will be invoked at least once within wait seconds (plus the time the method takes to execute).
Calls are “debounced” during that time, meaning that multiple calls to the decorated method will result in a single invocation.

Note

This functionality is similar to Underscore’s debounce, except that the Underscore method resets its timer on every call.

The decorated method is an instance of Debouncer, allowing it to be started and stopped.
This is useful when the method is a part of a Buildbot service: call method.start() from startService and method.stop() from stopService, handling its Deferred appropriately.

Stop the debouncer.
While the debouncer is stopped, calls to the decorated method will be ignored.
If a call is pending when stop is called, that call will occur immediately.
When the Deferred that stop returns fires, the underlying method is not executing.

Many Buildbot services perform some periodic, asynchronous operation.
Change sources, for example, contact the repositories they monitor on a regular basis.
The tricky bit is, the periodic operation must complete before the service stops.

This decorator replaces the decorated method with a Poller instance configured to call the decorated method periodically.
The poller is initially stopped, so periodic calls will not begin until its start method is called.
The start polling interval is specified when the poller is started.

If the decorated method fails or raises an exception, the Poller logs the error and re-schedules the call for the next interval.

If a previous invocation of the method has not completed when the interval expires, then the next invocation is skipped and the interval timer starts again.

A common idiom is to call start and stop from startService and stopService:

Several Buildbot components make use of maildirs to hand off messages between components.
On the receiving end, there’s a need to watch a maildir for incoming messages and trigger some action when one arrives.

A MaildirService instance watches a maildir for new messages.
It should be a child service of some MultiService instance.
When running, this class uses the linux dirwatcher API (if available) or polls for new files in the ‘new’ maildir subdirectory.
When it discovers a new message, it invokes its messageReceived method.

To use this class, subclass it and implement a more interesting messageReceived function.

This method is called with the short filename of the new message.
The full name of the new file can be obtained with os.path.join(maildir,'new',filename).
The method is un-implemented in the MaildirService class, and must be implemented in subclasses.

Cancel the given deferred after the given time has elapsed, if it has not already been fired.
Whent his occurs, the deferred’s errback will be fired with a twisted.internet.defer.CancelledError failure.

Similar to maildirs, netstrings are used occasionally in Buildbot to encode data for interchange.
While Twisted supports a basic netstring receiver protocol, it does not have a simple way to apply that to a non-network situation.

This class implements the AMQP-defined syntax: routing keys are treated as dot-separated sequences of words and matched against topics.
A star (*) in the topic will match any single word, while an octothorpe (#) will match zero or more words.

The classes in the buildbot.util.subscription module are used for master-local subscriptions.
In the near future, all uses of this module will be replaced with message-queueing implementations that allow subscriptions and subscribers to span multiple masters.

“Increment” an identifier by adding a numeric suffix, while keeping the total length limited.
This is useful when selecting a unique identifier for an object.
Maximum-length identifiers like _999999 cannot be incremented and will raise ValueError.

This class accepts a sequence of arbitrary strings and invokes a callback only with complete (newline-terminated) substrings.
It buffers any partial lines until a subsequent newline is seen.
It considers any of \r, \n, and \r\n to be newlines.
Because of the ambiguity of an append operation ending in the character \r (it may be a bare \r or half of \r\n), the last line of such an append operation will be buffered until the next append or flush.

This class is similar to twisted.application.service.MultiService, except that it handles Deferreds returned from child services startService and stopService methods.

Twisted’s service implementation does not support asynchronous startService methods.
The reasoning is that all services should start at process startup, with no need to coordinate between them.
For Buildbot, this is not sufficient.
The framework needs to know when startup has completed, so it can begin scheduling builds.
This class implements the desired functionality, with a parent service’s startService returning a Deferred which will only fire when all child services startService methods have completed.

This class also fixes a bug with Twisted’s implementation of stopService which ignores failures in the stopService process.
With AsyncMultiService, any errors in a child’s stopService will be propagated to the parent’s stopService method.

This class is similar to twisted.application.service.Service, except that its setServiceParent method will return a Deferred.
That Deferred will fire after the startService method has completed, if the service was started because the new parent was already running.

Some services in buildbot must have only one “active” instance at any given time.
In a single-master configuration, this requirement is trivial to maintain.
In a multiple-master configuration, some arbitration is required to ensure that the service is always active on exactly one master in the cluster.

For example, a particular daily scheduler could be configured on multiple masters, but only one of them should actually trigger the required builds.

A base class for a service that must have only one “active” instance in a buildbot configuration.

Each instance of the service is started and stopped via the usual twisted startService and stopService methods.
This utility class hooks into those methods in order to run an arbitration strategy to pick the one instance that should actually be “active”.

The arbitration strategy is implemented via a polling loop.
When each service instance starts, it immediately offers to take over as the active instance (via _claimService).

If successful, the activate method is called.
Once active, the instance remains active until it is explicitly stopped (eg, via stopService) or otherwise fails.
When this happens, the deactivate method is invoked and the “active” status is given back to the cluster (via _unclaimService).

If another instance is already active, this offer fails, and the instance will poll periodically to try again.
The polling strategy helps guard against active instances that might silently disappear and leave the service without any active instance running.

Subclasses should use these methods to hook into this activation scheme:

The “service id” uniquely represents this service in the cluster.
Each instance of this service must have this same id, which will be used in the arbitration to identify candidates for activation.
This method may return a Deferred.

An instance is attempting to become the one active instance in the cluster.
This method must return True or False (optionally via a Deferred) to represent whether this instance’s offer to be the active one was accepted.
If this returns True, the activate method will be called for this instance.

Surrender the “active” status back to the cluster and make it available for another instance.
This will only be called on an instance that successfully claimed the service and has been activated and after its deactivate has been called.
Therefore, in this method it is safe to reassign the “active” status to another instance.
This method may return a Deferred.

This class implements a generic Service that needs to be instantiated only once according to its parameters.
It is a common use case to need this for accessing remote services.
Having a shared service allows to limit the number of simultaneous access to the same remote service.
Thus, several completely independent Buildbot services can use that SharedService to access the remote service, and automatically synchronize themselves to not overwhelm it.

Reconfigurability would mean to add some kind of reference counting of the users, which will make the design much more complicated to use.
This means that the SharedService will not be destroyed when there is no more users, it will be destroyed at the master’s stopService
It is important that those SharedService life cycles are properly handled.
Twisted will indeed wait for any thread pool to finish at master stop, which will not happen if the thread pools are not properly closed.

The lifecycle of the SharedService is the same as a service, it must implement startService and stopService in order to allocate and free its resources.

Class method.
Takes same arguments as the constructor of the service.
Get a unique name for that instance of a service.
This returned name is the key inside the parent’s service dictionary that is used to decide if the instance has already been created before or if there is a need to create a new object.
Default implementation will hash args and kwargs and use <classname>_<hash> as the name.

Class method.
Takes same arguments as the constructor of the service (plus the parentService at the beginning of the list).
Construct an instance of the service if needed, and place it at the beginning of the parentService service list.
Placing it at the beginning will guarantee that the SharedService will be stopped after the other services.

This class is the combinations of all Service classes implemented in buildbot.
It is Async, MultiService, and Reconfigurable, and designed to be eventually the base class for all buildbot services.
This class makes it easy to manage (re)configured services.

The design separates the check of the config and the actual configuration/start.
A service sibling is a configured object that has the same name of a previously started service.
The sibling configuration will be used to configure the running service.

Service lifecycle is as follow:

Buildbot master start

Buildbot is evaluating the configuration file.
BuildbotServices are created, and checkConfig() are called by the generic constructor.

If everything is fine, all services are started.
BuildbotServices startService() is called, and call reconfigService() for the first time.

User reconfigures buildbot.

Buildbot is evaluating the configuration file.
BuildbotServices siblings are created, and checkConfig() are called by the generic constructor.

Please override this method to check the parameters of your config.
Please use buildbot.config.error for error reporting.
You can replace them *args,**kwargs by actual constructor like arguments with default args, and it have to match self.reconfigService
This method is synchronous, and executed in the context of the master.cfg.
Please don’t block, or use deferreds in this method.
Remember that the object that runs checkConfig is not always the object that is actually started.
The checked configuration can be passed to another sibling service.
Any actual resource creation shall be handled in reconfigService() or startService()

This method is called at buildbot startup, and buildbot reconfig.
*args and **kwargs are the configuration arguments passed to the constructor in master.cfg.
You can replace them*args,**kwargs by actual constructor like arguments with default args, and it have to match self.checkConfig

Returns a deferred that should fire when the service is ready.
Builds are not started until all services are configured.

BuildbotServices must be aware that during reconfiguration, their methods can still be called by running builds.
So they should atomically switch old configuration and new configuration, so that the service is always available.

If this method raises NotImplementedError, it means the service is legacy, and do not support reconfiguration.
The BuildbotServiceManager parent, will detect this, and swap old service with new service.
This behaviour allow smooth transition of old code to new reconfigurable service lifecycle but shall not be used for new code.

Internal method that finds the configuration bits in a sibling, an object with same class that is supposed to replace it from a new configuration.
We want to reuse the service started at master startup and just reconfigure it.
This method handles necessary steps to detect if the config has changed, and eventually call self.reconfigService()

Utility method which renders a list of parameters which can be interpolated as a secret.
This is meant for services which have their secrets parameter configurable as positional arguments.
If there are several argument, the secrets are interpolated in parallel, and a list of result is returned via deferred.
If there is one argument, the result is directly returned.

Note

For keyword arguments, a simpler method is to use the secrets class variable, which items
will be automatically interpolated just before reconfiguration.

secrets=("user","password")defreconfigService(self,user=None,password=None,...):# nothing to do user and password will be automatically interpolated

Advanced users can derive this class to make their own services that run inside buildbot, and follow the application lifecycle of buildbot master.

Such services are singletons accessible in nearly every objects of buildbot (buildsteps, status, changesources, etc) using self.master.namedServices[‘<nameOfYourService’].

As such, they can be used to factorize access to external services, available e.g using a REST api.
Having a single service will help with caching, and rate-limiting access of those APIs.

Here is an example on how you would integrate and configure a simple service in your master.cfg:

classMyShellCommand(ShellCommand):defgetResultSummary(self):# access the service attributeservice=self.master.namedServices['myService']returndict(step=u"arg value: %d"%(service.arg1,))classMyService(BuildbotService):name="myService"defcheckConfig(self,arg1):ifnotisinstance(arg1,int):config.error("arg1 must be an integer while it is %r"%(arg1,))returnifarg1<0:config.error("arg1 must be positive while it is %d"%(arg1,))defreconfigService(self,arg1):self.arg1=arg1returndefer.succeed(None)c['schedulers']=[ForceScheduler(name="force",builderNames=["testy"])]f=BuildFactory()f.addStep(MyShellCommand(command='echo hei'))c['builders']=[BuilderConfig(name="testy",workernames=["local1"],factory=f)]c['services']=[MyService(arg1=1)]

This class implements a SharedService for doing http client access.
The module automatically chooses from txrequests and treq and uses whichever is installed.
It provides minimalistic API similar to the one from txrequests and treq.
Having a SharedService for this allows to limits the number of simultaneous connection for the same host.
While twisted application can managed thousands of connections at the same time, this is often not the case for the services buildbot controls.
Both txrequests and treq use keep-alive connection polling.
Lots of HTTP REST API will however force a connection close in the end of a transaction.

Note

The API described here is voluntary minimalistic, and reflects what is tested.
As most of this module is implemented as a pass-through to the underlying libraries, other options can work but have not been tested to work in both backends.
If there is a need for more functionality, please add new tests before using them.

master – the instance of the master service (available in self.master for all the BuildbotService instances)

base_url – The base http url of the service to access. e.g. http://github.com/

auth – Authentication information. If auth is a tuple then BasicAuth will be used. e.g ('user','passwd')
It can also be a requests.auth authentication plugin.
In this case txrequests will be forced, and treq cannot be used.

headers – The headers to pass to every requests for this url

debug – log every requests and every response.

verify – disable the SSL verification.

Returns:

instance of :HTTPClientService

Get an instance of the SharedService.
There is one instance per base_url and auth.

The constructor initialize the service, and store the config arguments in private attributes.

This should not be overridden by subclasses, as they should rather override checkConfig.

IHTTPResponse is a subset of treqResponse API described here
The API it is voluntarily minimalistic and reflects what is tested and reliable to use with the three backends (including fake).
The api is a subset of the treq API, which is itself a superset of twisted IResponse API.
treq is thus implemented as passthrough.

Notably:

There is no api to automatically decode content, as this is not implemented the same in both backends.

There is no api to stream content as the two libraries have very different way for doing it, and we do not see use-case where buildbot would need to transfer large content to the master.

This class implements a fake version of the buildbot.util.httpclientservice.HTTPClientService that needs to be used for testing services which needs http client access.
It implements the same APIs as buildbot.util.httpclientservice.HTTPClientService, plus one that should be used to register the expectations.
It should be registered by the test case before the tested service actually requests an HTTPClientService instance, with the same parameters.
It will then replace the original implementation automatically (no need to patch anything).
The testing methodology is based on AngularJS ngMock.

on top of getService it will make sure the original HTTPClientService is not called, and assert that all expected http requests have been described in the test case.

expect(self, method, ep, params=None, data=None, json=None, code=200,

content=None, content_json=None):

Parameters:

method – expected HTTP method

ep – expected endpoint

params – optional expected query parameters

data – optional expected non-json data (bytes)

json – optional expected json data (dictionary or list or string)

code – optional http code that will be received

content – optional content that will be received

content_json – optional content encoded in json that will be received

Records an expectation of HTTP requests that will happen during the test.
The order of the requests is important.
All the request expectation must be defined in the test.

example:

fromtwisted.internetimportdeferfromtwisted.trialimportunittestfrombuildbot.test.fakeimporthttpclientserviceasfakehttpclientservicefrombuildbot.utilimporthttpclientservicefrombuildbot.utilimportserviceclassmyTestedService(service.BuildbotService):name='myTestedService'@defer.inlineCallbacksdefreconfigService(self,baseurl):self._http=yieldhttpclientservice.HTTPClientService.getService(self.master,baseurl)@defer.inlineCallbacksdefdoGetRoot(self):res=yieldself._http.get("/")# note that at this point, only the http response headers are receivedifres.code!=200:raiseException("%d: server did not succeed"%(res.code))res_json=yieldres.json()# res.json() returns a deferred to account for the time needed to fetch the entire bodydefer.returnValue(res_json)classTest(unittest.SynchronousTestCase):defsetUp(self):baseurl='http://127.0.0.1:8080'self.parent=service.MasterService()self._http=self.successResultOf(fakehttpclientservice.HTTPClientService.getFakeService(self.parent,self,baseurl))self.tested=myTestedService(baseurl)self.successResultOf(self.tested.setServiceParent(self.parent))self.successResultOf(self.parent.startService())deftest_root(self):self._http.expect("get","/",content_json={'foo':'bar'})response=self.successResultOf(self.tested.doGetRoot())self.assertEqual(response,{'foo':'bar'})deftest_root_error(self):self._http.expect("get","/",content_json={'foo':'bar'},code=404)response=self.failureResultOf(self.tested.doGetRoot())self.assertEqual(response.getErrorMessage(),'404: server did not succeed')

This module is a copy of twisted.internet.ssl except it won’t crash with ImportError if pyopenssl is not installed.
If you need to use twisted.internet.ssl, please instead use buildbot.util.ssl, and call ssl.ensureHasSSL in checkConfig to provide helpful message to the user, only if he enabled SSL for your plugin.