opendev/gerrit
Code Issues Proposed changes

Access control documentation: CI system example role

Browse Source 
The CI system has rights to download code and report a result back,
either through the Verify or the Code-review label.

Change-Id: I56eee9761ae54e1a0d3c05e6f109a7bd2d5526f8
Signed-off-by: Fredrik Luthander <fredrik.luthander@sonymobile.com>
This commit is contained in:
Fredrik Luthander
2012-01-27 12:44:05 +01:00
committed by Gustaf Lundh
parent 040834ffc4
commit f2105be098
1 changed files with 49 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

49
Documentation/access-control.txt
View File

@@ -841,6 +841,55 @@ Optional access rights to grant:
* <<category_push_merge,`Push merge commit`>> to 'refs/heads/*'
[[examples_cisystem]]
CI system
~~~~~~~~~
A typical Continous Integration system should be able to download new changes
to build and then leave a verdict somehow.
As an example, the popular
link:https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Trigger[gerrit-trigger plugin]
for Jenkins/Hudson can set labels at:
* The start of a build
* A successful build
* An unstable build (tests fails)
* A failed build
Usually the range chosen for this verdict is the verify label. Depending on
the size of your project and discipline of involved developers you might want
to limit access right to the +1 `Verify` label to the CI system only. That
way it's guaranteed that submitted commits always get built and pass tests
successfully.
If the build doesn't complete successfully the CI system can set the
`Verify` label to -1. However that means that a failed build will block
submit of the change even if someone else sets `Verify` +1. Depending on the
project and how much the CI system can be trusted for accurate results, a
blocking label might not be feasible. A recommended alternative is to set the
label `Code-review` to -1 instead, as it isn't a blocking label but still
shows a red label in the Gerrit UI. Optionally; to enable the possibility to
deliver different results (build error vs unstable for instance) it's also
possible to set `Code-review` +1 as well.
If pushing new changes are granted, it's possible to automate cherry-pick of
submitted changes for upload to other branches under certain conditions. This
is probably not the first step of what a project wants to automate however,
and so the push right can be found under the optional section.
Suggested access rights to grant, that won't block changes:
* <<category_read,`Read`>> on 'refs/heads/\*' and 'refs/tags/*'
* <<category_label-Code-Review,`Label: Code review`>> with range '-1' to '0'
* <<category_label-Verified,`Label: Verify`>> with range '0' to '+1'
Optional access rights to grant:
* <<category_label-Code-Review,`Label: Code review`>> with range '-1' to '+1'
* <<category_push,`Push`>> to 'refs/for/refs/heads/\*' and 'refs/changes/*'
[[conversion_table]]
Conversion table from 2.1.x series to 2.2.x series
--------------------------------------------------