ci-jobs.rst.inc (5429B)
1 .. _ci_var: 2 3 Custom CI/CD variables 4 ====================== 5 6 QEMU CI pipelines can be tuned by setting some CI environment variables. 7 8 Set variable globally in the user's CI namespace 9 ------------------------------------------------ 10 11 Variables can be set globally in the user's CI namespace setting. 12 13 For further information about how to set these variables, please refer to:: 14 15 https://docs.gitlab.com/ee/ci/variables/#add-a-cicd-variable-to-a-project 16 17 Set variable manually when pushing a branch or tag to the user's repository 18 --------------------------------------------------------------------------- 19 20 Variables can be set manually when pushing a branch or tag, using 21 git-push command line arguments. 22 23 Example setting the QEMU_CI_EXAMPLE_VAR variable: 24 25 .. code:: 26 27 git push -o ci.variable="QEMU_CI_EXAMPLE_VAR=value" myrepo mybranch 28 29 For further information about how to set these variables, please refer to:: 30 31 https://docs.gitlab.com/ee/user/project/push_options.html#push-options-for-gitlab-cicd 32 33 Setting aliases in your git config 34 ---------------------------------- 35 36 You can use aliases to make it easier to push branches with different 37 CI configurations. For example define an alias for triggering CI: 38 39 .. code:: 40 41 git config --local alias.push-ci "push -o ci.variable=QEMU_CI=1" 42 git config --local alias.push-ci-now "push -o ci.variable=QEMU_CI=2" 43 44 Which lets you run: 45 46 .. code:: 47 48 git push-ci 49 50 to create the pipeline, or: 51 52 .. code:: 53 54 git push-ci-now 55 56 to create and run the pipeline 57 58 59 Variable naming and grouping 60 ---------------------------- 61 62 The variables used by QEMU's CI configuration are grouped together 63 in a handful of namespaces 64 65 * QEMU_JOB_nnnn - variables to be defined in individual jobs 66 or templates, to influence the shared rules defined in the 67 .base_job_template. 68 69 * QEMU_CI_nnn - variables to be set by contributors in their 70 repository CI settings, or as git push variables, to influence 71 which jobs get run in a pipeline 72 73 * nnn - other misc variables not falling into the above 74 categories, or using different names for historical reasons 75 and not yet converted. 76 77 Maintainer controlled job variables 78 ----------------------------------- 79 80 The following variables may be set when defining a job in the 81 CI configuration file. 82 83 QEMU_JOB_CIRRUS 84 ~~~~~~~~~~~~~~~ 85 86 The job makes use of Cirrus CI infrastructure, requiring the 87 configuration setup for cirrus-run to be present in the repository 88 89 QEMU_JOB_OPTIONAL 90 ~~~~~~~~~~~~~~~~~ 91 92 The job is expected to be successful in general, but is not run 93 by default due to need to conserve limited CI resources. It is 94 available to be started manually by the contributor in the CI 95 pipelines UI. 96 97 QEMU_JOB_ONLY_FORKS 98 ~~~~~~~~~~~~~~~~~~~ 99 100 The job results are only of interest to contributors prior to 101 submitting code. They are not required as part of the gating 102 CI pipeline. 103 104 QEMU_JOB_SKIPPED 105 ~~~~~~~~~~~~~~~~ 106 107 The job is not reliably successsful in general, so is not 108 currently suitable to be run by default. Ideally this should 109 be a temporary marker until the problems can be addressed, or 110 the job permanently removed. 111 112 QEMU_JOB_PUBLISH 113 ~~~~~~~~~~~~~~~~ 114 115 The job is for publishing content after a branch has been 116 merged into the upstream default branch. 117 118 QEMU_JOB_AVOCADO 119 ~~~~~~~~~~~~~~~~ 120 121 The job runs the Avocado integration test suite 122 123 Contributor controlled runtime variables 124 ---------------------------------------- 125 126 The following variables may be set by contributors to control 127 job execution 128 129 QEMU_CI 130 ~~~~~~~ 131 132 By default, no pipelines will be created on contributor forks 133 in order to preserve CI credits 134 135 Set this variable to 1 to create the pipelines, but leave all 136 the jobs to be manually started from the UI 137 138 Set this variable to 2 to create the pipelines and run all 139 the jobs immediately, as was historicaly behaviour 140 141 QEMU_CI_AVOCADO_TESTING 142 ~~~~~~~~~~~~~~~~~~~~~~~ 143 By default, tests using the Avocado framework are not run automatically in 144 the pipelines (because multiple artifacts have to be downloaded, and if 145 these artifacts are not already cached, downloading them make the jobs 146 reach the timeout limit). Set this variable to have the tests using the 147 Avocado framework run automatically. 148 149 Other misc variables 150 -------------------- 151 152 These variables are primarily to control execution of jobs on 153 private runners 154 155 AARCH64_RUNNER_AVAILABLE 156 ~~~~~~~~~~~~~~~~~~~~~~~~ 157 If you've got access to an aarch64 host that can be used as a gitlab-CI 158 runner, you can set this variable to enable the tests that require this 159 kind of host. The runner should be tagged with "aarch64". 160 161 AARCH32_RUNNER_AVAILABLE 162 ~~~~~~~~~~~~~~~~~~~~~~~~ 163 If you've got access to an armhf host or an arch64 host that can run 164 aarch32 EL0 code to be used as a gitlab-CI runner, you can set this 165 variable to enable the tests that require this kind of host. The 166 runner should be tagged with "aarch32". 167 168 S390X_RUNNER_AVAILABLE 169 ~~~~~~~~~~~~~~~~~~~~~~ 170 If you've got access to an IBM Z host that can be used as a gitlab-CI 171 runner, you can set this variable to enable the tests that require this 172 kind of host. The runner should be tagged with "s390x". 173 174 CENTOS_STREAM_8_x86_64_RUNNER_AVAILABLE 175 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 176 If you've got access to a CentOS Stream 8 x86_64 host that can be 177 used as a gitlab-CI runner, you can set this variable to enable the 178 tests that require this kind of host. The runner should be tagged with 179 both "centos_stream_8" and "x86_64".