- Table Of Contents
- 1. Buildbot Tutorial
- 2. Buildbot Manual
- 2.1. Introduction
- 2.2. Installation
- 2.3. Concepts
- 2.4. Secret Management
- 2.5. Configuration
- 2.5.1. Configuring Buildbot
- 2.5.2. Global Configuration
- 2.5.3. Change Sources and Changes
- 2.5.5. Schedulers
- 2.5.6. Workers
- 2.5.7. Builder Configuration
- 2.5.8. Projects
- 2.5.9. Build Factories
- 2.5.10. Build Sets
- 2.5.11. Properties
- 2.5.12. Build Steps
- 2.5.12.1. Parameters Common to all Steps
- 2.5.12.2. Common Parameters of source checkout operations
- 2.5.12.3. Bzr
- 2.5.12.4. CVS
- 2.5.12.5. Darcs
- 2.5.12.6. Gerrit
- 2.5.12.7. GitHub
- 2.5.12.8. GitLab
- 2.5.12.9. Git
- 2.5.12.10. Mercurial
- 2.5.12.11. Monotone
- 2.5.12.12. P4
- 2.5.12.13. Repo
- 2.5.12.14. SVN
- 2.5.12.15. GitCommit
- 2.5.12.16. GitTag
- 2.5.12.17. GitPush
- 2.5.12.18. GitDiffInfo
- 2.5.12.19. ShellCommand
- 2.5.12.20. Shell Sequence
- 2.5.12.21. Compile
- 2.5.12.21. Compile
- 2.5.12.22. Configure
- 2.5.12.23. CMake
- 2.5.12.24. Visual C++
- 2.5.12.25. Cppcheck
- 2.5.12.26. Robocopy
- 2.5.12.27. Test
- 2.5.12.28. TreeSize
- 2.5.12.29. PerlModuleTest
- 2.5.12.30. SubunitShellCommand
- 2.5.12.31. HLint
- 2.5.12.32. MaxQ
- 2.5.12.33. Trigger
- 2.5.12.34. BuildEPYDoc
- 2.5.12.35. PyFlakes
- 2.5.12.36. Sphinx
- 2.5.12.37. PyLint
- 2.5.12.38. Trial
- 2.5.12.39. RemovePYCs
- 2.5.12.40. HTTP Requests
- 2.5.12.41. Worker Filesystem Steps
- 2.5.12.42. Transferring Files
- 2.5.12.44. MasterShellCommand
- 2.5.12.45. LogRenderable
- 2.5.12.47. SetProperty
- 2.5.12.46. Assert
- 2.5.12.48. SetProperties
- 2.5.12.49. SetPropertyFromCommand
- 2.5.12.51. RpmBuild
- 2.5.12.52. RpmLint
- 2.5.12.53. MockBuildSRPM Step
- 2.5.12.54. MockRebuild
- 2.5.12.55. DebPbuilder
- 2.5.12.57. DebLintian
- 2.5.13. Interlocks
- 2.5.14. Report Generators
- 2.5.15. Reporters
- 2.5.15.1. ReporterBase
- 2.5.15.2. BitbucketServerCoreAPIStatusPush
- 2.5.15.2. BitbucketServerCoreAPIStatusPush
- 2.5.15.3. BitbucketServerPRCommentPush
- 2.5.15.4. BitbucketServerStatusPush
- 2.5.15.6. GerritStatusPush
- 2.5.15.5. BitbucketStatusPush
- 2.5.15.7. GerritVerifyStatusPush
- 2.5.15.9. GitHubStatusPush
- 2.5.15.10. GitLabStatusPush
- 2.5.15.11. HttpStatusPush
- 2.5.15.12. IRC Bot
- 2.5.15.13. MailNotifier
- 2.5.15.14. PushjetNotifier
- 2.5.15.15. PushoverNotifier
- 2.5.15.16. Telegram Bot
- 2.5.15.17. ZulipStatusPush
- 2.5.16. Web Server
- 2.5.17. Change Hooks
- 2.5.18. Custom Services
- 2.5.19. DbConfig
- 2.5.20. Configurators
- 2.5.21. Manhole
- 2.5.22. Multimaster
- 2.5.23. Multiple-Codebase Builds
- 2.5.24. Miscellaneous Configuration
- 2.5.25. Testing Utilities
- 2.6. Customization
- 2.7. Command-line Tool
- 2.8. Resources
- 2.9. Optimization
- 2.10. Plugin Infrastructure in Buildbot
- 2.11. Deployment
- 2.12. Upgrading
- 3. Buildbot Development
- 3.1. Development Quick-start
- 3.2. Submitting Pull Requests
- 3.3. General Documents
- 3.3.1. Master Organization
- 3.3.2. Buildbot Coding Style
- 3.3.3. Buildbot’s Test Suite
- 3.3.4. Configuration
- 3.3.6. Writing Schedulers
- 3.3.7. Utilities
- 3.3.8. Build Result Codes
- 3.3.9. WWW Server
- 3.3.10. Javascript Data Module
- 3.3.11. Base web application
- 3.3.12. Authentication
- 3.3.13. Authorization
- 3.3.14. Master-Worker API
- 3.3.15. Master-Worker connection with MessagePack over WebSocket protocol
- 3.3.16. Claiming Build Requests
- 3.3.17. String Encodings
- 3.3.18. Metrics
- 3.3.19. Secrets
- 3.3.22. Statistics Service
- 3.3.23. How to package Buildbot plugins
- 3.4. REST API
- 3.5. REST API Specification
- 3.5.1. builder
- 3.5.2. buildrequest
- 3.5.3. build
- 3.5.4. buildset
- 3.5.5. build_data
- 3.5.6. change
- 3.5.7. changesource
- 3.5.8. forcescheduler
- 3.5.9. identifier
- 3.5.10. logchunk
- 3.5.11. log
- 3.5.12. master
- 3.5.13. patch
- 3.5.14. project
- 3.5.15. rootlink
- 3.5.16. scheduler
- 3.5.17. sourcedproperties
- 3.5.18. sourcestamp
- 3.5.19. spec
- 3.5.20. step
- 3.5.21. worker
- 3.5.22. test_result
- 3.5.23. testresultset
- 3.5.24. Raw endpoints
- 3.6. Data API
- 3.7. Database
- 3.8.1. Buildsets connector
- 3.8.2. Buildrequests connector
- 3.8.3. Builders connector
- 3.8.4. Builds connector
- 3.8.5. Build data connector
- 3.8.6. Steps connector
- 3.8.7. Logs connector
- 3.8.8. Changes connector
- 3.8.9. Change sources connector
- 3.8.10. Schedulers connector
- 3.8.11. Source stamps connector
- 3.8.12. State connector
- 3.8.13. Users connector
- 3.8.14. Masters connector
- 3.8.15. Workers connector
- 3.8. Database connectors API
- 3.9. Messaging and Queues
- 3.10. Classes
- 3.10.1. Builds
- 3.10.2. Workers
- 3.10.3. BuildFactory
- 3.10.4. Change Sources
- 3.10.5. RemoteCommands
- 3.10.6. BuildSteps
- 3.10.7. BaseScheduler
- 3.10.8. ForceScheduler
- 3.10.9. IRenderable
- 3.10.10. IProperties
- 3.10.11. IConfigurator
- 3.10.12. ResultSpecs
- 3.10.13. Protocols
- 3.10.14. WorkerManager
- 3.10.15. Logs
- 3.10.16. LogObservers
- 3.10.17. Authentication
- 3.10.18. Avatars
- 3.10.19. Web Server Classes
- 4. Release Notes
- 6. API Indices
- Release Notes
- 5.1. Buildbot 2.10.5 ( 2021-04-05 )
- 5.29. Release Notes for Buildbot 1.8.2 ( 2019-05-22 )
- 5.42. Release Notes for Buildbot 0.9.15.post1 ( 2018-01-07 )
- 5.60. Release Notes for Buildbot 0.9.1
- 5.61. Release Notes for Buildbot 0.9.0
- 5.62. Release Notes for Buildbot 0.9.0rc4
- 5.63. Release Notes for Buildbot 0.9.0rc3
- 5.64. Release Notes for Buildbot 0.9.0rc2
- 5.65. Release Notes for Buildbot 0.9.0rc1
- 5.66. Release Notes for Buildbot 0.9.0b9
- 5.67. Release Notes for Buildbot 0.9.0b8
- 5.68. Release Notes for Buildbot 0.9.0b7
- 5.69. Release Notes for Buildbot 0.9.0b6
- 5.70. Release Notes for Buildbot 0.9.0b5
- 5.71. Release Notes for Buildbot 0.9.0b4
- 5.72. Release Notes for Buildbot 0.9.0b3
- 5.73. Release Notes for Buildbot 0.9.0b2
- 5.74. Release Notes for Buildbot 0.9.0b1
- 5.75. Release Notes for Buildbot 0.8.11
- 5.76. Release Notes for Buildbot 0.8.10
- 5.77. Release Notes for Buildbot 0.8.9
- 5.78. Release Notes for Buildbot v0.8.8
- 5.79. Release Notes for Buildbot v0.8.7
- 5.80. Release Notes for Buildbot v0.8.6p1
- Other
3.3.10. Javascript Data Module
Caution
Buildbot no longer supports Python 2.7 on the Buildbot master.
3.3.10. Javascript Data Module
The Data module is a reusable AngularJS module used to access Buildbot’s data API from the browser. Its main purpose is to handle the 3 way binding.
2 way binding is the angular MVVM concept, which seamlessly synchronise the view and the model. Here, we introduce an additional way of synchronisation, which is from the server to the model.
We use the message queue and the websocket interfaces to maintain synchronisation between the server and the client.
The client application just needs to query the needed data using a highlevel API, and the data module uses the best approach to make the data always up to date.
Once the binding is set up by the controller, everything is automatically up to date.
3.3.10.1. Base Concepts
Collections
All the data you can get are Collections. Even a query to a single resource returns a collection. A collection is an Array subclass which has extra capabilities:
It listens to the event stream and is able to maintain itself up-to-date
It implements client side queries in order to guarantee up-to-date filtering, ordering and limiting queries.
It has a fast access to each item it contains via its id.
It has its own event handlers so that the client code can react when the Collection is changing
Wrappers
Each data type contained in a collection is wrapped in a javascript object. This allows to create some custom enhancements to the data model. For example, the Change wrapper decodes the author name and email from the “author” field.
Each wrapper class also has specific access methods, which allow to access more data from the REST hierarchy.
Installation
The Data module is available as a standalone AngularJS module.
Installation via yarn:
yarn add buildbot-data
Inject the bbData
module to your application:
angular.module('myApp', ['bbData'])
Service API
- class DataService()
DataService is the service used for accessing the Buildbot data API. It has a modern interface for accessing data in such a way that the updating of the data via web socket is transparent.
- DataService.open()
- Returns:
a DataAccessor which handles 3 way data binding
Open a new accessor every time you need to update the data in a controller.
It registers on $destroy event on the scope, and thus automatically unsubscribes from updates when the data is not used anymore.
// open a new accessor every time you need updating data in a controller class DemoController { constructor($scope, dataService) { // automatically closes all the bindings when the $scope is destroyed const data = dataService.open().closeOnDestroy($scope); // request new data, it updates automatically this.builders = data.getBuilders({limit: 10, order: '-started_at'}); } }
- DataService.getXs([id][, query])
Xs
can be the following:Builds
,Builders
,Buildrequests
,Buildsets
,Workers
,Changes
,Changesources
,Forceschedulers
,Masters
,Schedulers
,Sourcestamps
.It’s highly advised to use these methods instead of the lower level
get('string')
.- Returns:
collection which will eventually contain all the requested data
The collections returned without using an accessor are not automatically updated. So use those methods only when you know the data are not changing.
// assign builds to $scope.builds and then load the steps when the builds are discovered // onNew is called at initial load $scope.builds = dataService.getBuilds({builderid: 1}); $scope.builds.onNew = build => build.loadSteps();
- DataService.get(endpoint[, id][, query])
- Returns:
a collection; when the promise is resolved, the collection contains all the requested data
// assign builds to $scope.builds once the Collection is filled const builderid = 1; $scope.builds = dataService.get(`builders/${builderid}/builds`, {limit: 1}); $scope.builds.onNew = build => build.loadSteps();
// assign builds to $scope.builds before the Collection is filled using the // getArray() method $scope.builds = dataService.get('builds', {builderid: 1});
- DataService.control(url, method[, params])
- Returns:
a promise; sends a JSON RPC2 POST request to the server
// open a new accessor every time you need to update the data in a controller dataService.control('forceschedulers/force', 'force') .then(response => $log.debug(response), reason => $log.error(reason));
- class DataAccessor()
DataAccessor object is returned by the
dataService.open()
method.- DataAccessor.closeOnDestroy($scope)
Registers scope destruction as waterfall destruction for all collection accessed via this accessor.
- DataAccessor.close()
Destructs all collections previously accessed via this accessor. Destroying a collection means it will unsubscribe from any events necessary to maintain it up-to-date.
- DataAccessor.getXs([id][, query])
Same methods as in DataService, except here the data will be maintained up-to-date.
- Returns:
a collection which will eventually contain all the requested data
- class Collections()
- Collections.get(id)
This method does not do any network access, and thus only knows about data already fetched.
- Returns:
one element of the collection by id, or undefined, if this id is unknown to the collection.
- Collections.hasOwnProperty(id)
- Returns:
true if this id is known by this collection.
- Collections.close()
Forcefully unsubscribes this connection from auto-update. Normally, this is done automatically on scope destruction, but sometimes, when you got enough data, you want to save bandwidth and disconnect the collection.
- Collections.put(object)
Inserts one plain object to the collection. As an external API, this method is only useful for unit tests to simulate new data coming asynchronously.
- Collections.from(object_list)
Inserts several plain objects to the collection. This method is only useful for unit tests to simulate new data coming asynchronously.
- Collections.onNew = (object) ->()
Callback method which is called when a new object arrives in the collection. This can be called either when initial data is coming via REST API, or when data is coming via the event stream. The affected object is given in parameter. this context is the collection.
- Collections.onUpdate = (object) ->()
Callback method which is called when an object is modified. This is called when data is coming via the event stream. The affected object is given in parameter. this context is the collection.
- Collections.onChange = (collection) ->()
Callback method which is called when an object is modified. This is called when data is coming via the event stream. this context is the collection. The full collection is given in parameter (in case you override
this
via fat arrow).
- Collections.$ready
Attribute similar to what
ngResource
provides. True after first server interaction is completed, false before that. Knowing if the Collection has been resolved is useful in data-binding (for example to display a loading graphic).
- class Wrapper()
Wrapper objects are objects stored in the collection. These objects have specific methods, depending on their types.
- Wrapper.getXs([id][, query])
Same as
DataService.getXs
, but with a relative endpoint.- Returns:
a collection; when the promise is resolved, the collection contains all the requested data
// assign builds to $scope.builds once the Collection is filled $scope.builds = dataService.getBuilds({builderid: 1}); $scope.builds.onNew = function(b) { b.complete_steps = b.getSteps({complete:true}); b.running_steps = b.getSteps({complete:false}); };
- Wrapper.loadXs([id][, query])
o.loadXs()
is equivalent too.xs = o.getXs()
.- Returns:
a collection; the collection contains all the requested data, which is also assigned to
o.Xs
// get builder with id = 1 dataService.getBuilders(1).onNew = builder => { // load all builds in builder.builds builder.loadBuilds().onNew(build => { // load all buildsteps in build.steps build.loadSteps(); }); };
- Wrapper.control(method, params)
- Returns:
a promise; sends a JSON RPC2 POST request to the server
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论