James E. Blair | eff5a9d | 2017-06-20 00:00:37 -0700 | [diff] [blame] | 1 | :title: Job Content |
| 2 | |
| 3 | Job Content |
| 4 | =========== |
| 5 | |
| 6 | Zuul jobs are implemneted as Ansible playbooks. Zuul prepares the |
| 7 | repositories used for a job, installs any required Ansible roles, and |
| 8 | then executes the job's playbooks. Any setup or artifact collection |
| 9 | required is the responsibility of the job itself. While this flexible |
| 10 | arrangement allows for almost any kind of job to be run by Zuul, |
| 11 | batteries are included. Zuul has a standard library of jobs upon |
| 12 | which to build. |
| 13 | |
| 14 | Working Directory |
| 15 | ----------------- |
| 16 | |
| 17 | Before starting each job, the Zuul executor creates a directory to |
| 18 | hold all of the content related to the job. This includes some |
| 19 | directories which are used by Zuul to configure and run Ansible and |
| 20 | may not be accessible, as well as a directory tree, under ``work/``, |
| 21 | that is readable and writable by the job. The hierarchy is: |
| 22 | |
| 23 | **work/** |
| 24 | The working directory of the job. |
| 25 | |
| 26 | **work/src/** |
| 27 | Contains the prepared git repositories for the job. |
| 28 | |
| 29 | **work/logs/** |
| 30 | Where the Ansible log for the job is written; your job |
| 31 | may place other logs here as well. |
| 32 | |
| 33 | Git Repositories |
| 34 | ---------------- |
| 35 | |
| 36 | The git repositories in ``work/src`` contain the repositories for all |
| 37 | of the projects specified in the ``required-projects`` section of the |
| 38 | job, plus the project associated with the queue item if it isn't |
| 39 | already in that list. In the case of a proposed change, that change |
| 40 | and all of the changes ahead of it in the pipeline queue will already |
| 41 | be merged into their respective repositories and target branches. The |
| 42 | change's project will have the change's branch checked out, as will |
| 43 | all of the other projects, if that branch exists (otherwise, a |
| 44 | fallback or default branch will be used). If your job needs to |
| 45 | operate on multiple branches, simply checkout the appropriate branches |
| 46 | of these git repos to ensure that the job results reflect the proposed |
| 47 | future state that Zuul is testing, and all dependencies are present. |
| 48 | Do not use any git remotes; the local repositories are guaranteed to |
| 49 | be up to date. |
| 50 | |
| 51 | Note that these git repositories are located on the executor; in order |
| 52 | to be useful to most kinds of jobs, they will need to be present on |
| 53 | the test nodes. The ``base`` job in the standard library contains a |
| 54 | pre-playbook which copies the repositories to all of the job's nodes. |
| 55 | It is recommended to always inherit from this base job to ensure that |
| 56 | behavior. |
| 57 | |
| 58 | .. TODO: link to base job documentation and/or document src (and logs?) directory |
| 59 | |
| 60 | Zuul Variables |
| 61 | -------------- |
| 62 | |
| 63 | Zuul supplies not only the variables specified by the job definition |
| 64 | to Ansible, but also some variables from the executor itself. They |
| 65 | are: |
| 66 | |
| 67 | **zuul.executor.hostname** |
| 68 | The hostname of the executor. |
| 69 | |
| 70 | **zuul.executor.src_root** |
| 71 | The path to the source directory. |
| 72 | |
| 73 | **zuul.executor.log_root** |
| 74 | The path to the logs directory. |
| 75 | |
| 76 | SSH Keys |
| 77 | -------- |
| 78 | |
| 79 | Zuul starts each job with an SSH agent running and the key used to |
| 80 | access the job's nodes added to that agent. Generally you won't need |
| 81 | to be aware of this since Ansible will use this when performing any |
| 82 | tasks on remote nodes. However, under some circumstances you may want |
| 83 | to interact with the agent. For example, you may wish to add a key |
| 84 | provided as a secret to the job in order to access a specific host, or |
| 85 | you may want to, in a pre-playbook, replace the key used to log into |
| 86 | the assigned nodes in order to further protect it from being abused by |
| 87 | untrusted job content. |
| 88 | |
| 89 | .. TODO: describe standard lib and link to published docs for it. |
| 90 | |