taler-docs

Documentation for GNU Taler components, APIs and protocols
Log | Files | Refs | README | LICENSE

commit f136f335fb8ba3d4077b7ac4557e9f77099d976c
parent e942c6941340eaa2f5762a734d985ff9900a154d
Author: buckE <buckE@disroot.org>
Date:   Sun, 14 Jun 2020 05:17:43 +0000

buildbot five magic sentences added

Diffstat:
Mdevelopers-manual.rst | 29+++++++++++++++++++++++++++++
1 file changed, 29 insertions(+), 0 deletions(-)

diff --git a/developers-manual.rst b/developers-manual.rst @@ -315,6 +315,35 @@ run the following script from ``deployment/bin``: Environments and Builders on taler.net ====================================== +Buildbot implementation +----------------------- + +GNU Taler uses a buildbot implementation (front end at https://buildbot.taler.net) to manage continuous integration. Buildbot documentation is at https://docs.buildbot.net/. + +Here are some highlights: + +- The WORKER is the config that that lives on a shell account on a +localhost which has buildbot-worker. The WORKER executes the commands +that perform all end-functions of buildbot. + +- The WORKER running buildbot-worker receives these commands by +authenticating and communicating with the buildbot server. + +- The buildbot server's master.cfg file contains FACTORY declarations +which specify the commands to run on localhost. + +- The FACTORY is tied to the WORKER in master.cfg by a BUILDER. + +- The master.cfg also allows for SCHEDULER that defines how and when the +BUILDER is executed. + +- The master.cfg file is checked into git, and then periodically updated on the local account on taler.net (ask Christian for access if needed). Do not edit this file directly/locally for permanent changes. + +Best Practices: + +When creating a new WORKER in the `master.cfg` file, leave a comment specifying the server and user account that this WORKER is called from. (At this time, taler.net is the only server used by this implementation, but it's still good practice.) + + Documentation Builder ---------------------