In this post I’m going to describe the various components of Zuul, and how to run zuul-server in a Docker container in a lab setup.
This post is the third in a series of posts describing how I’ve used Docker to build a lab setup on my laptop to try out Zuul and check out its various features. Previously I’ve written about how I’ve started Jenkins and Gerrit to have the necessary services for Zuul to work against.
In order to gain a deep understanding of Zuul and prepare fur running it in production, I came up with a rather complex container layout . If you just want to see what Zuul looks like you can get a single container with everything (including Jenkins and Gerrit) here.
A fully functional Zuul system consists of several components:
In this post I’m going to describe how I quickly brought up Gerrit using Docker in a lab setup, and integrated it with Jenkins.
This post is the second in a series of posts describing how I’ve used Docker to build a lab setup on my laptop to try out Zuul and check out its various features.
Please see the previous post for an explanation of my goals, choice of tools and work done previously.
Since I’m focused on testing Zuul, I did not want to spend too much time setting up Gerrit. Instead I looked for a ready made container image that I could quickly bring up.
Gerrit, Jenkins and the Jenkins Gerrit Trigger Plugin make for a relatively easy way to setup an automated code review system. Using these components, you can have Jenkins run automates tests on code while it is being reviewed in Gerrit.
But as projects grow in complexity and amount of developers, some shortcomings of of this system become apparent as the reviewed code being tested in Jenkins stops reflecting the way it will actually look when merged into the main development branch. This is an issue we came across on oVirt’s CI system.
Looking for a solution, we found Zuul – a tool developed by the OpenStack community when they faced similar issues.
This post is a first in a series of posts describing how I’ve used Docker to build a lab setup on my laptop to try out Zuul and check out its various features.
Working with computers, be it system administration, or software development, as a profession, is a young one. As such, it has many ailments of youth: there is a tendency to lose track of a proper work/life balance, there is rampant professional burnout, there is career euthanasia.
One of the most striking ailments of the computing profession is the lack gender diversity. I have no doubt that having more women practice this profession will benefit it greatly and enhance its contribution to humanity. The few women in this profession, I’ve had the pleasure of meeting in my career, were, with no exception, remarkable and brilliant. I believe improving gender diversity will go a long way in tending other ailments of the profession I’ve mentioned.
So what can we, as veteran practitioners of the computing profession, charged with educating the next generation of practitioners, do to improve sexual diversity on our profession? We can start be telling young people that some of the most important tricks of the trade were dreamed up by woman. We can tell them the story of Grace Hopper.
BtSync App is a Linux portable AppImage containing BitTorrent Sync bundled with a Linux desktop GUI.
BitTorrent Sync is a free peer-to-peer cross-platform file synchronization application from BitTorrent Inc.
Linux AppImages enable delivering Linux applications as single, self-contained, executable files that work across distributions.
The AppImage includes the Linux desktop GUI for BitTorrent sync, developed by YeaSoft for the Debian BitTorrent Sync packages.
This AppImage is an UNOFFICIAL package of BitTorrent Sync and is not a product of BitTorrent Inc.
This AppImage in all its different versions, can be found on this GitHub releases page.
The source code used to build this AppImage and further information can be found in my GitHub repository.
I’m not sure if it really works, but I’m gonna try it…