Re-testing patches in Gerrit with Jenkins
Exherbo / March 5, 2014

A recent request concerned the possibility to re-test patches patches in Gerrit with Jenkins. I’ve now added a very simple switch for that: In any given given change (but your own!), you can add a comment with “+1 Retest” set as a “verdict”. On the old change screen (really, change to the new one, it’s much nicer), it looks like this:   On the new change screen, it looks like this: It’s really, truly easy. You can even do it multiple time – just uncheck the “Retest” checkbox (new screen) or set “0 Retest” (old screen) first and then set it again. This works for any change as long as you are a registered user – any change but your own. Unfortunately, the Jenkins’ Gerrit-Trigger plugin simply ignores the “CommentAdded” event completely for ones own changes. If you want those re-tested, just amend your commit (no need to actually change anything; the commit timestamp will be updated) and Jenkins will see the patch’s new revision and re-run the test.   On a side note, I’d like to apologise for the instability for about 1,5 days earlier this week. There were some really nasty hardware/software issue that I had to sort out. This is…

News about Gerrit, Jenkins & friends
Exherbo / December 29, 2013

Here are a few things I’ve updated on Gerrit, Jenkins and associated tools: Gerrit The Gerrit bot, gerritwk23, has now support for !pl (and pl in a query). It’s just like zebrapig’s !pl. I’ve updated Gerrit in mid-Decembre. Since then, you can switch to a newly designed “Change View” which you’ll find under your account’s settings in the “Change View” option. There’s also an associated “Diff View” option to set your preferred diff style if you switch to the new Change View. 2. Jenkins In its build logs, you’ll now find the mounts, the cave resolve command and the (likely) dependencies gathered from the installed package. Dependency information might not be 100% accurate so please take it with a grain of salt but it’s usually a good indicator. Look out for “**************************************************************” to find that information.   If you have any ideas about what else to improve, please let me know.

Another good reason to use Gerrit: Jenkins is at your service
Exherbo / December 1, 2013

If it’s not yet good enough for you that using Gerrit is even easier and faster than using zebrapig (you just push your change and you’re done! And if you use git review it’s getting even easier.), the review turn-around times are often better when using Gerrit than zebrapig, discussing patches can be done both when you’re on IRC and on Gerrit, then here’s another good reason to use it: I’ve set up Jenkins for all repositories on Gerrit to build every change in a chroot (including sydbox-1, pinktrace-1 and docs). For now, all reports only go to me (and anyone else who wants to get an email with the result included) and Jenkins will not report back to Gerrit because the setup is quite fragile yet and I want to be sure it works properly before making it do more. No idea how to use Gerrit? Just read my earlier posts Gerrit Code Review for Exherbo and Gerrit for Core-Devs. Of course, you can ask me, too. 🙂  

Exherbo’s Gerrit for 3rd party repositories
Exherbo / November 28, 2013

Exherbo’s Gerrit has left its infancy and, thus, I can now add 3rd party repositories to our Gerrit installation. Please just let me know if you’d like that. Requirements: Your repository must use git. You must have an account in Gerrit. You must be willing to add a Gerrit user (github: Gerrit-Exherbo; BitBucket: gerrit-exherbo) to your repository as a contributor.  Here’s the public key. (You don’t need the public key for github or BitBucket; if you’re unsure, you most likely don’t need it.) Your repository should be hosted on one of the big git hosting providers, e. g. github (preferred) or BitBucket. Let me know if your repository is hosted elsewhere. Please let me know the push URI for your repository. Once I’ve set you up, you can immediately work on Gerrit patches for your repository. You are, of course, its sole owner and fully responsible for it. By default, Exherbo’s core devs (but nobody else unless you explicitly ask me to add someone) will be able to +2 Gerrit changes for your repository, too. This is meant to potentially help you keep your repository up to date (e. g. when mass changes occur). This is entirely optional, though, and you can choose to opt-out at any time…

Gerrit for Core-Devs
Exherbo / September 29, 2013

There have been a few questions and potential misunderstandings I’m going to try to address here. I’ll update this post if new stuff comes up. Getting the foo Or: How do I become a Core-Dev on Gerrit? Simple: You register with your GitHub or Google account, then you ask any other core dev to add you to the group. At least Bo “zlin” Ørsted Andresen and I know how to do it and every member has the necessary privileges. Reviewing Or: +1+1 != +2 Every registered user can comment and/or -1/+1 a change. This is an indication said user has reviewed the patch and, ideally, tested it. It’s basically only an opinion, though. Only Core-Devs can +2 a change. This means they’ve reviewed and tested that change and are approving it. The change then will get merged and pushed. It’s important to remember, though, that +1’s do NOT add up. You can +1 a change a hundred times but it will still need one bold man (or woman) to +2 it. Important as well, don’t forget to press the “Submit” button if you want to get a change merged. What about testing (or the lack of)? Everyone who +2’s a change at least (ideally, +1 would…

Gerrit Code Review for Exherbo
Exherbo / September 15, 2013

This post is outdated and only kept for historical reasons. I’ve installed a Gerrit Code Review instance on my server for use with Exherbo. Gerrit is a code review tool and allows for discussing patches and keeping the results for future reference get notified by email about changes (if you want) easily work on every Exherbo repository contributors to get their repositories added to Gerrit as well (optional but strongly recommended) You’ll find an introduction to Gerrit here. Notes: You need a GitHub or Google account. The email address you wish to use in Gerrit must be configured in your GitHub account. You MUST use your real name for copyright reasons. Gerrit replicates merged changes pretty much immediately. This sometimes/rarely fails on the first attempt for various reason. I’ve implemented a fallback that occurs every 5 minutes. How to use Gerrit: Initial setup in two easy steps: Go to, in the upper right corner, click “Sign in”. Authorize Gerrit with GitHub or Google.  Cloning a repository: Click “Projects”, “List”, then choose a project. You should see several methods for cloning the project, the easiest way is to choose the ssh method. Clone, e. g. git clone ssh://<user name> Install a hook that sets a Change-Id automatically…