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
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.json
,toolchains.json
, andplatforms.json
. - Shared pipeline library:
vars/
andresources/
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-2023 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.