- 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
2.5.17. Change Hooks
Caution
Buildbot no longer supports Python 2.7 on the Buildbot master.
2.5.17. Change Hooks
The /change_hook
URL is a magic URL which will accept HTTP requests and translate them into changes for Buildbot. Implementations (such as a trivial json-based endpoint and a GitHub implementation) can be found in master/buildbot/www/hooks. The format of the URL is /change_hook/DIALECT
where DIALECT is a package within the hooks directory. change_hook
is disabled by default and each DIALECT has to be enabled separately, for security reasons.
An example www
configuration line which enables change_hook and two DIALECTS:
c['www'] = dict( change_hook_dialects={ 'base': True, 'somehook': {'option1':True, 'option2':False}, }, )
Within the www
config dictionary arguments, the change_hook
key enables/disables the module, and change_hook_dialects
whitelists DIALECTs where the keys are the module names and the values are optional arguments which will be passed to the hooks.
The master/contrib/post_build_request.py script allows for the submission of an arbitrary change request. Run post_build_request.py --help for more information. The base
dialect must be enabled for this to work.
2.5.17.1. Change Hooks Auth
By default, the change hook URL is not protected. Some hooks implement their own authentication method. Others require the generic method to be secured.
To protect URL against unauthorized access, you may use change_hook_auth
option.
Note
This method uses HTTP BasicAuth
. It implies the use of SSL via Reverse Proxy Configuration in order to be fully secured.
from twisted.cred import strcred c['www'] = dict(..., change_hook_auth=[strcred.makeChecker("file:changehook.passwd")], )
Create a file changehook.passwd
with content:
user:password
change_hook_auth
should be a list of ICredentialsChecker
. See the details of available options in Twisted documentation.
Note
In the case of the "file:changehook.passwd"
description in makeChecker, Buildbot checkconfig
might give you a warning “not a valid file: changehook.passwd”. To resolve this, you need specify the full path to the file, f"file:{os.path.join(basedir, 'changehook.passwd')}"
.
2.5.17.2. Mercurial hook
The Mercurial hook uses the base dialect:
c['www'] = dict( ..., change_hook_dialects={'base': True}, )
Once this is configured on your buildmaster add the following hook on your server-side Mercurial repository’s hgrc
:
[hooks] changegroup.buildbot = python:/path/to/hgbuildbot.py:hook
You’ll find master/contrib/hgbuildbot.py, and its inline documentation, in the buildbot-contrib repository.
2.5.17.3. GitHub hook
Note
There is a standalone HTTP server available for receiving GitHub notifications as well: master/contrib/github_buildbot.py. This script may be useful in cases where you cannot expose the WebStatus for public consumption. Alternatively, you can setup a reverse proxy Reverse Proxy Configuration.
The GitHub hook has the following parameters:
secret
(default None)Secret token to use to validate payloads.
strict
(default False)If the hook must be strict regarding valid payloads. If the value is False (default), the signature will only be checked if a secret is specified and a signature was supplied with the payload. If the value is True, a secret must be provided, and payloads without signature will be ignored.
codebase
(default None)The codebase value to include with created changes. If the value is a function (or any other callable), it will be called with the GitHub event payload as argument and the function must return the codebase value to use for the event.
github_property_whitelist
(default [])A list of
fnmatch
expressions which match against the flattened pull request information JSON prefixed withgithub
. For examplegithub.number
represents the pull request number. Available entries can be looked up in the GitHub API Documentation or by examining the data returned for a pull request by the API.class
(default None)A class to be used for processing incoming payloads. If the value is None (default), the default class –
buildbot.www.hooks.github.GitHubEventHandler
– will be used. The default class handles ping, push and pull_request events only. If you’d like to handle other events (see Event Types & Payloads for more information), you’d need to subclassGitHubEventHandler
and add handler methods for the corresponding events. For example, if you’d like to handle blah events, your code should look something like this:from buildbot.www.hooks.github import GitHubEventHandler class MyBlahHandler(GitHubEventHandler): def handle_blah(self, payload): # Do some magic here return [], 'git'
skips
(default[r'\[ *skip *ci *\]', r'\[ *ci *skip *\]']
)A list of regex pattern makes buildbot ignore the push event. For instance, if user push 3 commits and the commit message of branch head contains a key string
[ci skip]
, buildbot will ignore this push event.If you want to disable the skip checking, please set it to
[]
.github_api_endpoint
(defaulthttps://api.github.com
)If you have a self-host GitHub Enterprise installation, please set this URL properly.
token
If your GitHub or GitHub Enterprise instance does not allow anonymous communication, you need to provide an access token. Instructions can be found here.
pullrequest_ref
(defaultmerge
)Remote ref to test if a pull request is sent to the endpoint. See the GitHub developer manual for possible values for pull requests. (e.g.
head
)
The simplest way to use GitHub hook is as follows:
c['www'] = dict( change_hook_dialects={'github': {}}, )
Having added this line, you should add a webhook for your GitHub project (see Creating Webhooks page at GitHub). The parameters are:
- Payload URL
This URL should point to
/change_hook/github
relative to the root of the web status. For example, if the base URL ishttp://builds.example.com/buildbot
, then point GitHub tohttp://builds.example.com/buildbot/change_hook/github
. To specify a project associated to the repository, append?project=name
to the URL.- Content Type
Specify
application/x-www-form-urlencoded
orapplication/json
.- Secret
Any value. If you provide a non-empty value (recommended), make sure that your hook is configured to use it:
c['www'] = dict( ..., change_hook_dialects={ 'github': { 'secret': 'MY-SECRET', }, }, )
- Which events would you like to trigger this webhook?
Click –
Let me select individual events
, then selectPush
andPull request
– other kind of events are not currently supported.
And then press the Add Webhook
button.
Github hook creates 3 kinds of changes, distinguishable by their category
field:
None
: This change is a push to a branch.Use
util.ChangeFilter(category=None, repository="http://github.com/<org>/<project>")
'tag'
: This change is a push to a tag.Use
util.ChangeFilter(category='tag', repository="http://github.com/<org>/<project>")
'pull'
: This change is from a pull-request creation or update.Use
util.ChangeFilter(category='pull', repository="http://github.com/<org>/<project>")
. In this case, theGitHub
step must be used instead of the standardGit
in order to be able to pull GitHub’s magic refs. With this method, theGitHub
step will always checkout the branch merged with latest master. This allows to test the result of the merge instead of just the source branch. Note that you can use theGitHub
for all categories of event.
Warning
Pull requests against every branch will trigger the webhook; the base branch name will be in the basename
property of the build.
Warning
The incoming HTTP requests for this hook are not authenticated by default. Anyone who can access the web server can “fake” a request from GitHub, potentially causing the buildmaster to run arbitrary code.
To protect URL against unauthorized access you should use
The BitBucket hook is as simple as the GitHub one and takes no options.
c['www'] = dict(..., change_hook_dialects={'bitbucket': True}, )
When this is set up, you should add a POST service pointing to /change_hook/bitbucket
relative to the root of the web status. For example, if the grid URL is http://builds.example.com/bbot/grid
, then point BitBucket to http://builds.example.com/change_hook/bitbucket
. To specify a project associated to the repository, append ?project=name
to the URL.
Note that there is a standalone HTTP server available for receiving BitBucket notifications, as well: master/contrib/bitbucket_buildbot.py. This script may be useful in cases where you cannot expose the WebStatus for public consumption.
Warning
As in the previous case, the incoming HTTP requests for this hook are not authenticated by default. Anyone who can access the web status can “fake” a request from BitBucket, potentially causing the buildmaster to run arbitrary code.
To protect URL against unauthorized access you should use
c['www'] = dict( ..., change_hook_dialects={'bitbucketcloud': {}}, )
When this is set up, you should add a webhook pointing to /change_hook/bitbucketcloud
relative to the root of the web status.
According to the type of the event, the change category is set to push
, pull-created
, pull-rejected
, pull-updated
, pull-fulfilled
or ref-deleted
.
The Bitbucket Cloud hook may have the following optional parameters:
codebase
(default None)The codebase value to include with changes or a callable object that will be passed the payload in order to get it.
bitbucket_property_whitelist
(default [])A list of
fnmatch
expressions which match against the flattened pull request information JSON prefixed withbitbucket
. For examplebitbucket.id
represents the pull request ID. Available entries can be looked up in the BitBucket API Documentation or by examining the data returned for a pull request by the API.
Warning
The incoming HTTP requests for this hook are not authenticated by default. Anyone who can access the web server can “fake” a request from Bitbucket Cloud, potentially causing the buildmaster to run arbitrary code.
2.5.17.6. Bitbucket Server hook
c['www'] = dict( ..., change_hook_dialects={'bitbucketserver': {}}, )
When this is set up, you should add a webhook pointing to /change_hook/bitbucketserver
relative to the root of the web status.
According to the type of the event, the change category is set to push
, pull-created
, pull-rejected
, pull-updated
, pull-fulfilled
or ref-deleted
.
The Bitbucket Server hook may have the following optional parameters:
codebase
(default None)The codebase value to include with changes or a callable object that will be passed the payload in order to get it.
bitbucket_property_whitelist
(default [])A list of
fnmatch
expressions which match against the flattened pull request information JSON prefixed withbitbucket
. For examplebitbucket.id
represents the pull request ID. Available entries can be looked up in the BitBucket API Documentation or by examining the data returned for a pull request by the API.
Warning
The incoming HTTP requests for this hook are not authenticated by default. Anyone who can access the web server can “fake” a request from Bitbucket Server, potentially causing the buildmaster to run arbitrary code.
Note
This hook requires the bitbucket-webhooks plugin (see https://marketplace.atlassian.com/plugins/nl.topicus.bitbucket.bitbucket-webhooks/server/overview).
2.5.17.7. Poller hook
The poller hook allows you to use GET or POST requests to trigger polling. One advantage of this is your buildbot instance can poll at launch (using the pollAtLaunch flag) to get changes that happened while it was down, but then you can still use a commit hook to get fast notification of new changes.
Suppose you have a poller configured like this:
c['change_source'] = SVNPoller( repourl="https://amanda.svn.sourceforge.net/svnroot/amanda/amanda", split_file=split_file_branches, pollInterval=24*60*60, pollAtLaunch=True, )
And you configure your WebStatus to enable this hook:
c['www'] = dict(..., change_hook_dialects={'poller': True}, )
Then you will be able to trigger a poll of the SVN repository by poking the /change_hook/poller
URL from a commit hook like this:
curl -s -F poller=https://amanda.svn.sourceforge.net/svnroot/amanda/amanda \ http://yourbuildbot/change_hook/poller
If no poller
argument is provided then the hook will trigger polling of all polling change sources.
You can restrict which pollers the webhook has access to using the allowed
option:
c['www'] = { ..., 'change_hook_dialects': { 'poller': { 'allowed': ['https://amanda.svn.sourceforge.net/svnroot/amanda/amanda'] } } }
2.5.17.8. GitLab hook
c['www'] = dict(..., change_hook_dialects={ 'gitlab' : { 'secret': '...', }, }, )
The GitLab hook has the following parameters:
secret
(default None)Secret token to use to validate payloads.
When this is set up, you should add a POST service pointing to /change_hook/gitlab
relative to the root of the web status. For example, if the grid URL is http://builds.example.com/bbot/grid
, then point GitLab to http://builds.example.com/change_hook/gitlab
. The project and/or codebase can also be passed in the URL by appending ?project=name
or ?codebase=foo
to the URL. These parameters will be passed along to the scheduler.
Note
To handle merge requests from forks properly, it’s easiest to use a GitLab source step rather than a Git source step.
Note
Your Git or GitLab step must be configured with a git@ repourl, not a https: one, else the change from the webhook will not trigger a build.
Warning
As in the previous case, the incoming HTTP requests for this hook are not authenticated by default. Anyone who can access the web status can “fake” a request from your GitLab server, potentially causing the buildmaster to run arbitrary code.
Warning
When applicable, you need to permit access to internal/local networks. See https://docs.gitlab.com/ee/security/webhooks.html
for details.
To protect URL against unauthorized access you should either
set secret token in the configuration above, then set it in the GitLab service hook declaration, or
use the
The Gitorious hook is as simple as GitHub one and it also takes no options.
c['www'] = dict(..., change_hook_dialects={'gitorious': True}, )When this is set up, you should add a POST service pointing to
/change_hook/gitorious
relative to the root of the web status. For example, if the grid URL ishttp://builds.example.com/bbot/grid
, then point Gitorious tohttp://builds.example.com/change_hook/gitorious
.Warning
As in the previous case, the incoming HTTP requests for this hook are not authenticated by default. Anyone who can access the web status can “fake” a request from your Gitorious server, potentially causing the buildmaster to run arbitrary code.
To protect URL against unauthorized access you should use
Custom hooks are supported via the Plugin Infrastructure in Buildbot mechanism. You can subclass any of the available hook handler classes available in
buildbot.www.hooks
and register it in the plugin system via a custom python module. For convenience, you can also use the generic optioncustom_class
, e.g.:from buildbot.plugins import webhooks class CustomBase(webhooks.base): def getChanges(self, request): args = request.args chdict = dict( revision=args.get(b'revision'), repository=args.get(b'repository'), project=args.get(b'project'), codebase=args.get(b'codebase')) return ([chdict], None) c['www'] = dict(..., change_hook_dialects={ 'base' : { 'custom_class': CustomBase, }, }, )
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论