michaeldo | 8cccf214 | 2017-03-06 22:12:02 | [diff] [blame] | 1 | # Continuous build and test infrastructure for Chromium for iOS |
| 2 | |
| 3 | See the [instructions] for how to check out and build Chromium for iOS. |
| 4 | |
| 5 | The Chromium projects use buildbot for continuous integration. This doc starts |
| 6 | with an overview of the system, then gives detailed explanations about each |
| 7 | part. |
| 8 | |
| 9 | [TOC] |
| 10 | |
| 11 | ## Overview |
| 12 | |
| 13 | Commits are made using the [commit queue], which triggers a series of try jobs |
| 14 | to compile and test the proposed patch against Chromium tip of tree before |
| 15 | actually making the commit. If the try jobs succeed the patch is committed. A |
| 16 | newly committed change triggers the builders (or "bots") to compile and test |
| 17 | the change again. |
| 18 | |
| 19 | ## Bots |
| 20 | |
| 21 | Bots are slaves attached to a buildbot master (or "waterfall"). A buildbot |
| 22 | master is a server which polls for commits to a repository and triggers workers |
| 23 | to compile and test new commits whenever they are detected. [chromium.mac] is |
| 24 | the main waterfall for Mac desktop and iOS. [tryserver.chromium.mac] serves |
| 25 | as the try server for Mac desktop and iOS. |
| 26 | |
| 27 | The bots know how to check out a given revision of Chromium, compile, and test. |
| 28 | |
| 29 | ### Code location |
| 30 | |
| 31 | #### Master configs |
| 32 | |
| 33 | The masters are configured in [tools/build], a separate repository which |
| 34 | contains various infra-related scripts. |
| 35 | |
| 36 | #### Pollers |
| 37 | |
| 38 | [chromium.mac] uses a `GitilesPoller` which polls the Chromium repository for |
| 39 | new commits using the [gitiles] interface. When a new commit is detected, the |
| 40 | bots are triggered. |
| 41 | |
| 42 | #### Recipes |
| 43 | |
| 44 | The bots run [recipes], which are scripts that specify their sequence of steps |
| 45 | located in [tools/build]. An iOS-specific [recipe module] contains common |
| 46 | functionality that the various [iOS recipes] use. |
| 47 | |
| 48 | #### Configs |
| 49 | |
| 50 | Because the recipes live in another repository, changes to the recipes don't |
| 51 | go through the Chromium [commit queue] and aren't tested on the [try server]. |
| 52 | In order to allow bot changes to be tested by the commit queue, the recipes |
| 53 | for iOS are generic instead of bot-specific, and rely on configuration files |
| 54 | which live in master-specific JSON config files located in [src/ios/build/bots]. |
| 55 | These configs define the `gn_args` to use during compilation as well as the |
| 56 | tests to run. |
| 57 | |
| 58 | #### Scripts |
| 59 | |
| 60 | The [test runner] is the script which installs and runs the tests, interprets |
| 61 | the results, and collects any files emitted by the test ("test data"). It can |
| 62 | be found in [src/ios/build/bots/scripts], which means changes to the test runner |
| 63 | can be tested on the [try server]. |
| 64 | |
| 65 | ### Compiling with goma |
| 66 | |
| 67 | Goma is the distributed build system used by Chromium. It reduces compilation |
| 68 | time by avoiding recompilation of objects which have already been compiled |
| 69 | elsewhere. |
| 70 | |
| 71 | ### Testing with swarming |
| 72 | |
| 73 | Tests run on [swarming], a distributed test system used by Chromium. After |
| 74 | compilation, configured tests will be zipped up along with their necessary |
| 75 | dependencies ("isolated") and sent to the [swarming server] for execution. The |
| 76 | server issues tasks to its attached workers for execution. The bots themselves |
|
|