Jenkins
Introduction
Jenkins is a Java-based automation server. Typical simple use-case would be to use this for
continuous integration by automatically building, testing, and deploying code.
Pipeline as Code
The new preferred way to manage Jenkins jobs is through a Jenkinsfile, a file literally named just "Jenkinsfile" which you save to the root directory of your project and commit to your preferred CVS. This is the configuration of all "steps" you want to perform on your code, typically build, test, and deploy. A Jenkins Pipeline will run each step as long as the previous one is successful.
Here's an example of a Jenkinsfile used with a Jenkins Multibranch Pipeline and Gradle.
Jenkinsfile
pipeline {
agent any
stages {
stage('Build') {
steps {
sh 'env'
sh 'gradle clean build --version'
sh 'gradle war'
sh 'echo workspace: ${WORKSPACE}'
sh 'ls ${WORKSPACE}/build/libs'
}
}
stage('Test') {
steps {
sh 'gradle cleanTest test'
junit '**/test-results/test/*.xml'
}
}
stage('Deploy to Dev') {
steps {
sh 'asadmin deploy --user=admin --passwordfile=/nfs/classe/glassfish-dev/glassfish/domains/domain1/config/.passwordfile --host=glassfish-dev --force=true ${WORKSPACE}/build/libs/chargedistro.war'
}
}
}
}
To use Gradle, you save and commit a file named build.gradle to your project's root directory as well. The purpose of Gradle in this example is to download dependencies (Ant is not able to do this), create the WAR file, and run the tests (e.g. JUnit, etc.).
Gradle uses default standard locations where it expects to find things like the java files, test files, and the web app files. However, if you've created web projects in Netbeans, these standards were most likely not followed. However, Gradle does not impose structure on your project, but instead allows you to override the default values.
In this particular file example, Gradle is being used with an exisiting Ant build.xml file, which can easily be imported and can be entirely replaced either piecemeal or all at once.
build.gradle
apply plugin: 'war'
webAppDirName = 'web'
ant.importBuild('build.xml') { antTargetName ->
'a-' + antTargetName
}
repositories {
mavenCentral()
}
dependencies {
compile 'javax:javaee-api:7.0'
testCompile "junit:junit:4.11"
}
war {
baseName 'chargedistro'
from('src/java/resources') {
include '**/*.properties'
into 'WEB-INF/classes/resources'
}
from('src/conf') {
include 'persistence.xml'
into 'WEB-INF/classes/META-INF'
}
}
sourceSets {
main {
java {
srcDir 'src/java'
}
}
test {
java {
srcDir 'test'
}
}
}
Multibranch Pipeline
A Mulitbranch Pipeline is a very convenient Jenkins job that will periodically scan a project's repository indexing all trunk, branches, and tags directories and will automatically create a pipeline for each as long as each root directory has a Jenkinsfile.
That means if you add a branch tomorrow with a Jenkinsfile, the pipeline for that branch will be created automatically. Also, if the Multibranch Pipeline job finds differences in the CVS for a particular branch (including trunk and tags), it will kick off the appropriate pipelines to rebuild, retest, and redeploy the code for that branch.
Gradle
GitLab - another option for implementing CI at CLASSE.