Jervis: Jenkins as a service

• Project status: released to maven central.
• Currently Targeted platforms:
  • Jenkins server host: Linux and Mac OS X (Windows compatible)
  • Jobs on clients: Linux only (Multi-platform capable)

What is Jervis?

• What is Jervis? A library for Job DSL plugin
  scripts and shared Jenkins pipeline libraries. It is used to
  augment the automation of generating Jenkins jobs.
• SCM Filter Jervis plugin is available for multibranch
  pipline filtering. Installing this plugin also makes the Jervis library
  available for import in shared pipeline libraries.

Documentation

• Jervis Wiki
  • Build Overview
  • Supported Languages
  • Supported Build Tools

The library API is also fully documented. To generate the
latest developer docs execute the following command.

./gradlew groovydoc

The documentation can be found in build/docs/groovydoc.

Provided examples

• Bootstrapping Jenkins: Example bootstrap for
  Jenkins which allows you to quickly try out this
  library.
• Job DSL Script: Example Job DSL script is
  provided.
• Jenkins build node: There’s also a docker container designed
  to be used as a Jenkins build agent through the Jenkins Docker
  Plugin.
• Jervis configuration files: lifecycles.yaml,
  toolchains.yaml, and platforms.yaml.
• Shared pipeline library: vars/ and resources/
  directories.

More about Jervis

Jervis is a combination of some letters in the words Jenkins and Travis: JEnkins
tRaVIS. Jenkins is a continuous integration tool which is
typically installed on premises. Travis is a hosted, distributed
continuous integration system used by many open source projects.
Both Jenkins and Travis have paid and enterprise offerings.

Jervis uses Travis-like job generation using the Job DSL
plugin and groovy scripts. It reads the .jervis.yml
file of a project and generates a job in Jenkins based on it. If .jervis.yml
doesn’t exist then it will fall back to using the .travis.yml
file.

For development planning and other documentation see the Jervis
wiki. If you wish to stay up to date with the latest Jervis news
then please feel free to watch this repository because I use the
issue tracking and wiki for planning.

Why Jervis?

What is Jervis attempting to scale? Let’s talk about some scale bottlenecks
that have been overcome by Jenkins (formerly Hudson) and its community.

The scaling issue is a main bullet. The solution for the issue is in a
sub-bullet.

• Developers are challenged with integrating work, building often, and even
  deploying often.
  • Jenkins was invented.
• Jenkins infrastructure is strained when too many agents are in one server and
  too many jobs are queued up on a daily basis. A single Jenkins server
  struggles to perform all requested builds in a timely manner. Jenkins also
  suffers from single point of failure as a lone server.
  • Multi-controller Jenkins was invented. This provides redundancy for the
    server. Throughput for daily build capacity is improved.
• Jenkins jobs suffer from a lot of duplicate code. It is difficult to fix a
  bug in one job and have it propagate to other jobs.
  • Jenkins Job DSL plugin was invented. Configuration through code is now
    possible. Multiple jobs can be generated and regenerated with the same code
    using templates in a domain specific language.
• Onboarding new projects in a Jenkins installation can be difficult. Typically
  engineers will get together and discuss the needs of the project and then
  configure a Jenkins job for the needs of the project. For enterprises with a
  very large number of projects it is typically hard to scale number of build
  engineers to match with the large number of projects which require onboarding
  into the build ecosystem.
  • Jervis is being invented. Job generation through convention over
    configuration. Scaling the onboarding for a project by creating and abiding
    by conventions in how jobs are generated. This is for large scale job
    generation and project onboarding. Jervis is taking lessons learned from a
    seasoned build engineer and attempting to fill this gap in the Jenkins
    ecosystem.

Set up

To include this library for use in your Job DSL plugin scripts you only need
include it in your build tool.

Maven

<dependency>
  <groupId>net.gleske</groupId>
  <artifactId>jervis</artifactId>
  <version>2.0</version>
  <type>pom</type>
</dependency>

Gradle

Your Job DSL scripts should have a build.gradle file which has the following
contents.

apply plugin: 'maven'
repositories {
    mavenCentral()
}
configurations {
    libs
}
dependencies {
    libs 'net.gleske:jervis:2.0'
    libs 'org.yaml:snakeyaml:2.0'
}
task cleanLibs(type: Delete) {
    delete 'lib'
}
task libs(type: Copy) {
    into 'lib'
    from configurations.libs
}
defaultTasks 'clean', 'libs'
clean.dependsOn cleanLibs

Then execute ./gradlew libs to assemble dependencies into the lib directory
of the Jenkins workspace. Don’t forget to add lib to the classpath. This
must be done before you configure your Jenkins job to execute Job DSL scripts.

Interactive debugging

Groovy Console is built into the Gradle file.

./gradlew console

Other development commands

Generate code coverage reports.

./gradlew clean check jacocoTestReport

Build the jar file.

./gradlew clean jar

Sign build jars and sign archives.

./gradlew clean check signArchives

See also RELEASE.md.

Local SonarQube Analysis

See SonarQube README.

License

Copyright 2014-2024 Sam Gleske
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
   http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.