Intro to a Jenkins Pipeline
This section is not about what Jenkins is. We are going to dig in deeper and configure the build and release of an application!
As mentioned in the Jenkins introduction, when working with Jenkins, it is all about the plugins.
Jenkins plugins are separated in to sections by the type of action they perform. This information is pretty reliable, but it is also self selected by plugin authors and not a curated list. Such is the life of open source projects, but going to the official Jenkins Plugins page and searching for any plugins related to tools you use is still a great starting point.
Configuration "Magic"
There is no magic. There is just experience from playing with the tool. Configuring Jenkins plugins can be a lot of trial and error. But that is okay! You are not going to hurt anything when making a mistake in your testing environments. Unfortauntely not all of the plugins have the best documentation. But you will eventually get to your desired end state/configuration. Which means - just like your code, you want to take advantage of development environments. You do not want to configure jobs the first time when editing production Jenkins environments. Figure out the configuration for development processes and then move it out to production.
Remember - Jenkins will only do what you tell it to do.
Workout
The standard starting point is to have Jenkins build, or compile, something. So we've got a sample web application we are going to start with. After it has been built, we will want to store the build artifact and notify users the build ran.
Not a lot to talk about here - but lots to do. So let's dive in!
- Get in the
deployments
directory of the Automation Tools git repo andvagrant up
our trusty VM. - Start up a Jenkins server using Docker container.
docker run -p 8080:8080 -p 50000:50000 -v /home/vagrant/jenkins_home:/var/jenkins_home jenkins:1.625.2
- Install the following list of plugins on your new Jenkins server.
- SCM Sync Configuration Plugin
- NodeJS Plugin
- GitHub Plugin
- Copy Artifact Plugin
- Slack Plugin
- Gatling Plugin
- With the plugins installed, it is time to configure them.
- Configure SCM Sync to use a new public repo on GitHub. (For today this is good, in general don't use this with a public repo)
- Configure the NodeJS plugin to install the latest version (or 5.x version) of NodeJS for our test project to use.
- Make your own room in Automation Tools Slack
- Configure the Slack plugin with your own Slack room's API key.
- Create a new Freestyle Jenkins job named
create-build-artifact
that checks out our example application you forked and have write access to. - "Validate" we have a working application by running
npm install; npm test
in an Execute Shell. - Setup the Jenkins to check repo every two minutes
*/2 * * * *
, or "when a change is pushed to GitHub". - Add a Post Build step to post in your Slack channel the result of the build
- Manually run this new job and ensure everything performed as expected!
- Create another new Freestyle Jenkins job named
create-atb-container
- Have it check out your forked copy of the example Docker project.
- Then it will use the Copy Artifact Plugin copy in the tested Node.js application files from
create-build-artifact
to your new job's workspace in a folder you will callnode-app
. - Then run
docker build -t localhost:5002/atb
command generate a container of the example Node.js app. - Now we have a container to publish to Artifactory. Have Jenkins do this with the
docker push localhost:5002/atb:0.0.1
command. - Go to your Artifactory Server and browse to the
docker-dev-local2
repo and see your uploaded container! - BONUS item: Create a GitHub issue in your project and reference it in the following
git commit
message and see what integrations happen then. - Now change the version number in the Example Node app's
package.json
file from0.0.1
to0.0.2
in your GitHub repository.git commit
andgit push
them and watch the entire pipeline run again.