This document discusses integrating Gerrit code review with Jenkins automation using Docker containers. It presents a use case of mobile development where Gerrit is used for centralized source and code review, Jenkins for automation and integration, and Repo for cross-repository features. It then introduces using the Gerrit Trigger plugin and Jenkins Workflow together as of August 2015 to handle multiple parallel jobs more cleanly and with built-in concurrency and failure handling options. The demonstration is dockerized using images from Gerritforge and Jenkins to showcase the integration.
08448380779 Call Girls In Civil Lines Women Seeking Men
Gerrit & Jenkins Workflow: An Integrated CI Demonstration
1. Gerrit & Jenkins Workflow: An
Integrated Demonstration
Code Review and Automation, All In Docker
For Gerrit User Summit 2015
2. Real World Use Case: Mobile Development
●Gerrit: Centralized Source and Code Review
●Jenkins: Automation and Integration
●Repo: Cross-repository Features (Android use)
3. Gerrit/Jenkins Solutions
●Gerrit Trigger + chained jobs
●Gerrit hooks firing Jenkins jobs
●Multiple Jobs with Gerrit trigger configured
*NEW* Gerrit Trigger + Jenkins Workflow *NEW*
Available as of Aug 2015
Parameterized trigger: supports workflow as of Aug 2015
4. Gerrit + CI Pain Points
●Fast feedback?
●Sequences of test jobs?
●Orphaned jobs?
6. Why Gerrit Trigger + Workflow for Gerrit CI integration?
●Gerrit hooks or gerrit trigger on multiple jobs solved a
problem: how do I handle multiple parallel jobs?
○ This does it a lot more cleanly though
●Highly configurable
●Built-in concurrency & fail-fast options
●Lives in SCM, it can live in Gerrit and be
reviewed separately
●Failure handling: try/catch and finally
Grateful for the opportunity to present here, this is a little bit different, but I hope you’ll find it of useful
Please hold the questions, I’ll pause periodically for questions -- skimming through a lot of material fast
Who here uses Jenkins? Who here uses the Jenkins Gerrit Trigger? Who has used the Jenkins workflow plugin? And who here uses Docker? (Result: Jenkins & Gerrit Trigger are used overwhelmingly, workflow & docker much less so).
This is based on a real-world customer using this tool combination
All of these are common solutions to CI/CD integration with Gerrit and Jenkins, but the older solutions each have problems, as we’ll touch on in the next slide. Today I offer a new solution that has recently become available, which presents a better solution.
Problems:
Fast is critical: parallel execution is a MUST HAVE for CI, as is fail-fast for parallel branches (report failures ASAP)
Chained job lists become complex to maintain -- if you use different branch configs, this gets more complex, though templates help.
Chaining jobs requires passing all configuration information as parameters from job to job -- gets messy fast!
Gerrit hooks require gerrit-side configuration and do not maintain a clean separation of concerns for CI/CD server and code review
Multiple jobs with triggers & chained jobs need to ensure that the pipeline does not generate orphaned jobs (wasted resources or environments)
Multiple jobs need to ensure voting is handled correctly by each, and provide feedback in a consistent fashion to users
This is the configuration we’re showing today:
Note that we’re doing parallel Linux, android, and windows builds
Some of the tests give very fast feedback (seconds or minutes), others take hours or even overnight (complex UI automation)
Some of the tests require significant system resources to run
Keep it simple: this is sort of the opposite of the Mesos installs (a small, simple case for users)
This is an integration example, so it leverages many existing technologies
Demo:
Push + parallel jobs: see how a single workflow job can trigger many concurrent build steps very simply? Code as your build pipeline!
Push + breakage case: parallel workflow steps can fail fast, so any failure kills the flow and notifies your developers immediately!
Amending commit: kills running job and restarts a fresh one! No more “oops, re-push… and wait for CI”
Naming: containers need to see each other, and the names need to be consistent with clients (including use of repo)
Solutions: container names, links, and DNS servers. For local work, /etc/hosts is a suitable hack.
Dirty Hax Warning: For Demo Purposes, I Do Some Nasty Things, especially with configuration (keys, etc)
Binary configs are a challenge for doing Docker image development in git - H2 DB
Option to use SSH commands to land configuration?
Run DB as separate container?
Internal git repos are a pain point for saving Docker image development in git
Mount them as volumes or clone in from externally if you want to preload the image