James E. Blair | 4076e2b | 2014-01-28 12:42:20 -0800 | [diff] [blame] | 1 | :title: Merger |
| 2 | |
| 3 | Merger |
| 4 | ====== |
| 5 | |
| 6 | The Zuul Merger is a separate component which communicates with the |
| 7 | main Zuul server via Gearman. Its purpose is to speculatively merge |
| 8 | the changes for Zuul in preparation for testing. The resulting git |
| 9 | commits also must be served to the test workers, and the server(s) |
| 10 | running the Zuul Merger are expected to do this as well. Because both |
| 11 | of these tasks are resource intensive, any number of Zuul Mergers can |
| 12 | be run in parallel on distinct hosts. |
| 13 | |
| 14 | Configuration |
| 15 | ~~~~~~~~~~~~~ |
| 16 | |
| 17 | The Zuul Merger can read the same zuul.conf file as the main Zuul |
| 18 | server and requires the ``gearman``, ``gerrit``, ``merger``, and |
| 19 | ``zuul`` sections (indicated fields only). Be sure the zuul_url is |
| 20 | set appropriately on each host that runs a zuul-merger. |
| 21 | |
| 22 | Zuul References |
| 23 | ~~~~~~~~~~~~~~~ |
| 24 | |
| 25 | As the DependentPipelineManager may combine several changes together |
| 26 | for testing when performing speculative execution, determining exactly |
| 27 | how the workspace should be set up when running a Job can be complex. |
| 28 | To alleviate this problem, Zuul performs merges itself, merging or |
| 29 | cherry-picking changes as required and identifies the result with a |
| 30 | Git reference of the form ``refs/zuul/<branch>/Z<random sha1>``. |
| 31 | Preparing the workspace is then a simple matter of fetching that ref |
| 32 | and checking it out. The parameters that provide this information are |
| 33 | described in :ref:`launchers`. |
| 34 | |
| 35 | These references need to be made available via a Git repository that |
| 36 | is available to Jenkins. This is accomplished by serving Zuul's Git |
| 37 | repositories directly. |
| 38 | |
| 39 | Serving Zuul Git Repos |
| 40 | ~~~~~~~~~~~~~~~~~~~~~~ |
| 41 | |
| 42 | Zuul maintains its own copies of any needed Git repositories in the |
| 43 | directory specified by ``git_dir`` in the ``merger`` section of |
| 44 | zuul.conf (by default, /var/lib/zuul/git). To directly serve Zuul's |
| 45 | Git repositories in order to provide Zuul refs for Jenkins, you can |
| 46 | configure Apache to do so using the following directives:: |
| 47 | |
| 48 | SetEnv GIT_PROJECT_ROOT /var/lib/zuul/git |
| 49 | SetEnv GIT_HTTP_EXPORT_ALL |
| 50 | |
| 51 | AliasMatch ^/p/(.*/objects/[0-9a-f]{2}/[0-9a-f]{38})$ /var/lib/zuul/git/$1 |
| 52 | AliasMatch ^/p/(.*/objects/pack/pack-[0-9a-f]{40}.(pack|idx))$ /var/lib/zuul/git/$1 |
| 53 | ScriptAlias /p/ /usr/lib/git-core/git-http-backend/ |
| 54 | |
| 55 | And set ``push_change_refs`` to ``false`` (the default) in the |
| 56 | ``zuul`` section of zuul.conf. |
| 57 | |
| 58 | Note that Zuul's Git repositories are not bare, which means they have |
| 59 | a working tree, and are not suitable for public consumption (for |
| 60 | instance, a clone will produce a repository in an unpredictable state |
| 61 | depending on what the state of Zuul's repository is when the clone |
| 62 | happens). They are, however, suitable for automated systems that |
| 63 | respond to Zuul triggers. |