Let's take a look at the generated Jenkinsfile, which has our pipeline definitions using the Groovy DSL:
#!/usr/bin/env groovy
node {
stage('checkout') {
checkout scm
}
stage('check java') {
sh "java -version"
}
stage('clean') {
sh "chmod +x gradlew"
sh "./gradlew clean --no-daemon"
}
stage('install tools') {
sh "./gradlew yarn_install -PnodeInstall --no-daemon"
}
stage('backend tests') {
try {
sh "./gradlew test -PnodeInstall --no-daemon"
} catch(err) {
throw err
} finally {
junit '**/build/**/TEST-*.xml'
}
}
stage('frontend tests') {
try {
sh "./gradlew yarn_test -PnodeInstall --no-daemon"
} catch(err) {
throw err
} finally {
junit '**/build/test-results/karma/TESTS-*.xml'
}
}
stage('packaging') {
sh "./gradlew bootRepackage -x test -Pprod -PnodeInstall --
no-daemon"
archiveArtifacts artifacts: '**/build/libs/*.war',
fingerprint: true
}
stage('deployment') {
sh "./gradlew deployHeroku --no-daemon"
}
}
We have multiple stages defined running in a sequence, highlighted in bold; there are eight to be exact. It starts with a checkout of the branch from version control ending with deployment to Heroku (we will see more about this in the following chapter).
The steps are quite straightforward as most of it is just triggering a Gradle task. Let's look at each of them:
stage('checkout') {
checkout scm
}
The checkout stage does a local checkout of the source code revision that triggered the build:
stage('check java') {
sh "java -version"
}
This check java stage just prints the Java version installed on the Jenkins environment:
stage('clean') {
sh "chmod +x gradlew"
sh "./gradlew clean --no-daemon"
}
The clean stage first grants execution permission for the Gradle wrapper on a Unix-like OS and then executes the Gradle clean task. The --no-daemon flag disables the Gradle daemon feature, which is not required in a CI environment:
stage('install tools') {
sh "./gradlew yarn_install -PnodeInstall --no-daemon"
}
The install tools stage makes sure that NodeJS and all the NPM modules are installed by running yarn install via Gradle.
The -PnodeInstall flag ensures that NodeJS is installed first if not done already:
stage('backend tests') {
try {
sh "./gradlew test -PnodeInstall --no-daemon"
} catch(err) {
throw err
} finally {
junit '**/build/**/TEST-*.xml'
}
}
The backend tests stage runs all the server-side integration and unit tests by triggering the Gradle test task. It will fail the Jenkins pipeline when there is an error and register the test reports on the Jenkins web UI using the JUnit plugin after the test run is complete:
stage('frontend tests') {
try {
sh "./gradlew yarn_test -PnodeInstall --no-daemon"
} catch(err) {
throw err
} finally {
junit '**/build/test-results/karma/TESTS-*.xml'
}
}
Similar to previously, the frontend tests stage runs the client-side unit tests by triggering the yarn test command via a Gradle task. It will also fail the pipeline on an error and register the test reports on the Jenkins web UI:
stage('packaging') {
sh "./gradlew bootRepackage -x test -Pprod -PnodeInstall --no-
daemon"
archiveArtifacts artifacts: '**/build/libs/*.war', fingerprint:
true
}
The packaging stage triggers the Gradle bootRepackage task with the prod profile and archives the created WAR files with a unique fingerprint:
stage('deployment') {
sh "./gradlew deployHeroku --no-daemon"
}
The final stage is for deployment and it also uses a Gradle task for this. We will see this in detail in the following chapter. For now, let's comment out this stage. We will re-enable it later.
Now let's commit everything to git by running these commands. Make sure you are on the master branch, else commit and merge the branch with the master:
> git add --all
> git commit -am "add Jenkins pipeline for ci/cd"