workflow A patch is intended to: Be mailed to the dev@-mailinglist Being picked up by a developer with commit rights and be Checked for a valid license Reviewed for Goodness Applied, Build, Tested and Pushed Reported back to the mailing list that this is in now Reality: fdo#40946
speeds. Tinderboxes know nothing of each other. Tinderboxes cant communicate or coordinate. The slowest and rarest tinderboxes (Windows) are the most valueable.
Gerrit: Automatic Patch Uploads Intergration in a wide range of communication channels Human Review Tinderbox Review Testsuite Review Thus: Find errors early and before they cause too much pain.
good to me -2 → violent opposition Later: +1 → at least doesnt look like a trojan to me Verified: (blackbox testing: observations without looking at the code) +1 → passes all tests I subjected it to recommended: at least building on one platform -1 → failed in some way (building, testing)
Yes, better tools sometimes result in less interaction The “saved” interactions are usually of the annoying kind anyway: Repetitive, Administrative and Blocking Lets keep up a good amount of personal interaction, with the time saved from the better tools: Public personal comments
is now integrated with: Mailing lists Bugzilla (oneway) IRC git commandline (git review and logerrit) Still needs to be integrated with: (volunteers welcome!) RSS Twitter (trivial with twitterfeed once RSS is there) Identica g+
runs on Ubuntu 11.10 Will be migrated to 12.04 soon :-) Services are separated on Linux LXC-Containers Every important Service has its own LXC-Container Details on IS see IS-Talk Friday (F. Effenberger / A.Werner)
the LXC-Container (Puppet) Installtion of Dependencies (Apache / PostgreSQL) Download of gerrit from google-Sites Installation of gerrit based on http://gerrit-documentation.googlecode.com/svn/Documentation/2.4.2/install.html Future: our own Puppet-Plugin for Installation / Upgrade
Backup-Structure based on BackupPC Backup is done twice a day Backup is stored on two Backup-Machines Future (after Migration to 12.04): LVM-Snapshot-Backup of LXC-Container + Snapshot of Database Downtime per Backup about 1 sec.
(without gerrit) 1/3 Independent tinderboxes that periodically check master and release branches Multiple checks for the same commits on the same platforms possible Build and configuration logic is located locally in tinbuild2 script Report results to tinderbox master per fire and forget Tinderbox master presents results in a web page
with gerrit 1/3 Some kind of queue manager is needed to distribute checks jobs between tinderboxes One patch set must be checked only once for each platform and configuration Tinbuild2 must be teached to talk to queue manager Results from all tinderboxes are gathered and combined result is reported back to gerrit A patch set is approved only when all check jobs were successful.
set Consumption gerrit-stream events Communication API/protocol for tinderboxen Job Scheduler Build log publication and visualization Internal pipeline visualization Documentation Nice to have: Gerrit web ui extension check job results are reported in own table on change page in gerrit during review process specific configuration can be selected to be checked, i. e. with-java if java stack was changed in change context
Since upcoming gerrit 2.5 plugin architecture is introduced What can a gerrit plugin extend? New ssh commands under plugin's own namespace New plugin web pages under plugin's own namespace Extend database Highly experimental and not in upcoming release 2.5: web ui extension of core pages (GWT and javascript plugin types) Dog fooding: Replication is a gerrit plugin now and not a core feature https://review.gerrit.net/plugins/plugin-name-1.0/page.html ssh gerrit plugin-name-1.0 some-really-cool-command --foo --bar baz
as gerrit plugin 2/6 Consumption gerrit stream events Trivially as gerrit plugin: just a callback Communication API/protocol (for tinbuild2 and other clients) Gerrit ssh command: Job Scheduler Internally job queue is maintained and can be polled per ssh command: Result reporting and build log publication per ssh: ssh logerrit buildbot-1.0 get-task --project core --platform linux ssh logerrit buildbot-1.0 show-queue –project core cat log | ssh logerrit buildbot-1.0 report --ticket 4711 --failed
as gerrit plugin 4/6 Documentation: per ssh ssh logerrit buildbot-1.0 report --help buildbot-1.0 report [--] [--failed (-f)] [--help (-h)] [--log (-l) -|LOG] [--succeed (-s)] --ticket (-t) TICKET -- : end of options --failed (-f) : specify this option if job failed --help (-h) : display this help text --log (-l) -|LOG : url of the job log page or - for standard input --succeed (-s) : specify this option if job was successfull --ticket (-t) TICKET : ticket of the job
as gerrit plugin 6/6 Result are presented in gerrit's comment table Nice to have: Implement CI verification status table on gerrit's change page (once web ui plugin can extend core pages) Don't mix human's review and CI's verification outcome
in this document is licensed under the Creative Commons Attribution-Share Alike 3.0 License (unless otherwise specified). "LibreOffice" and "The Document Foundation" are registered trademarks. Their respective logos and icons are subject to international copyright laws. The use of these therefore is subject to the trademark policy. ??? Questions ???
sweetshark1
oskmr
seike460
bkuhlmann
quiver
ikumatadokoro
mraible
kj455
luisasofie_xoxo
kishida
kosmosebi
tomu28
addyosmani
philnash
smashingmag
lauravandoore
keithpitt
caitiem20
searls
davidbonilla
eileencodes
ufuk
kevinliebholz
tenderlove
![14 Crowdsourcing code review Gerrit Maildrop Send to [email protected] Subject:](https://files.speakerdeck.com/presentations/508842b6db554a0002069d49/slide_13.jpg){kind=link}
