← Older revision
Revision as of 09:33, 24 November 2012
Line 2:
Line 2:
== Tools ==
== Tools ==
+
+
We are using third party open source software, the most important ones are:
; Gerrit
; Gerrit
−
: it hosts the WMF git repository and provides an interface to review the code. Developers send a patchset which is then enqueued in the review queue and is not actually merged until it has been approved. Whenever a patchset is sent or is approved, Gerrit generates an event we react on.
+
: Hosts the WMF git repository and provides an interface to review the code. Developers send a patchset which is then enqueued in the review queue and is not actually merged until it has been approved. Whenever a patchset is sent or is approved, Gerrit generates an event we react on.
; Jenkins
; Jenkins
−
: This is a job control system which can be used to run unit tests, generate tarballs or whatever we can think about. Each job is a set of instructions (such as running a shell script or reporting test result) and can accept parameters to finely tune the job execution.
+
: A job control system which can be used to run unit tests, generate tarballs or whatever we can think about. Each job is a set of instructions (such as running a shell script or reporting test result) and can accept parameters to finely tune the job execution.
; Zuul
; Zuul
−
: Is a daemon listening for Gerrit events, according to a workflow specification file, it can trigger Jenkins jobs and pass them various parameters (ex: the Gerrit change number).
+
: listens for Gerrit events, according to a workflow specification file, it can trigger Jenkins jobs and pass them various parameters (ex: the Gerrit change number).
+
+
; Jenkins job builder
+
: craft jobs for Jenkins based on a flat file specification, save us from having to click checkboxes in Jenkins graphical interface.
== Roles ==
== Roles ==
−
We identify several user roles:
+
We identify two user roles:
; Contributor
; Contributor
−
: Anyone modifying a file hosted by the WMF. The modification can be code, translations, documentation update. Contributor send their change to Gerrit using git. Any contributor is allowed to review any change, comment on it and gives his feedback by voting the code-review label (-1 to +1).
+
: Willing to modify a git repository hosted by the WMF, be it code, translation, documentation update... Contributors send their changes to Gerrit using git. Any contributor is allowed to review any change, comment on it and gives its feedback by voting the code-review label (-1 to +1).
−
; Reviewer
+
; Gate keeper
−
: Those people are the gate keepers, they have the ability to approve a change which will in turn trigger unit tests and merge the change in the repository. They can also prevent a change from being sent by voting code-review label -2.
+
: They approve changes which will in turn trigger unit tests and merge the change in the repository. They can also prevent a change from being sent by voting code-review label -2.
== From patch to merge ==
== From patch to merge ==
−
Whenever a patch is uploaded, we run basic checks to detect the most trivial errors. Whenever the checks fails, the contributor is shown a list of action to handle and invited to update a new patch.
+
Whenever an action is conducted in Gerrit, Zuuls receive an event. It is passed through a set of rules that might end up triggering an event for Jenkins. Most projects have, or will have, a rule on patchset creation that will trigger a run of basic checks (linting, trivial errors). Whenever the checks fails, Zuul will comment on Gerrit change and list the URL pointing to Jenkins jobs consoles. Moreover, Zuul is able vote on Verified / Code-Review labels, when basic checks are successful, Zuul can flag the change has Verified which also mean the change is ready to be reviewed by a human being. Developers, testers or even a non coders will have a look at the code sent, test it and comment about possible issues.
−
−
Once the checks have been completed, Jenkins will flag the change has Verified which also mean the change is ready to be reviewed by a human being. Developers, testers or even a non coders will have a look at the code sent, test it and comment about possible issues.
−
Each person can vote under the Code-Review with a score varying from -2 (do not submit/merge) to +2 (change approved). Only projects owner and trusted people are able to actually approve a change. Whenever a +2 vote is casted, unit tests are run. For MediaWiki core this include attempting to install MediaWiki and running the full PHPUnit test suite. If the test suite fail, the change is verified and prevented from being submitted (Code-Review -2). If all tests are successfull, change is ready to be merged.
+
Each person can vote under the Code-Review with a score varying from -2 (do not submit/merge) to +2 (change approved). Only projects owner and trusted people are able to actually approve a change. They have the power to decide how the software is evolving and guarantee the nothing bad will happen in production. Whenever a +2 vote is casted, unit tests are run. For MediaWiki core this include attempting to install MediaWiki and running the full PHPUnit test suite. If the test suite fail, the change is verified and prevented from being submitted (Code-Review -2). If all tests are successfull, change is ready to be merged.
Basically:
Basically: