As we saw earlier, Jenkins works by creating and executing jobs. Historically, one way to create the pipeline would be to open Jenkins in our browser, navigate to the job we previously created, and edit it to outline the different steps involved in testing our code. The problem with that solution is that there isn't a good review process involved and it's hard to track every change made over time. In addition, it's very hard for developers to make changes in a project that involve adding new build steps as the code of the project and the job building the project aren't synced together. Jenkins 2 made the concept of describing the build process into a local file a standard feature. We are going to use it. Here is how.

We are going to create and edit a new file in the project called Jenkinsfile (Capital J, no file extension). The file will be written in Groovy (http://www.groovy-lang.org).

On the first line of the file, we are going to put the following:

#!groovy 

This is a best practice mostly useful to the different integrated development environments (IDEs) and to GitHub as they will understand the nature of the file. The first step of our script will consist of asking Jenkins to assign the job to a node like so:

node { } 

Our Jenkins installation is fairly simple. We only one have server and therefore one node. If we had more nodes, we could add parameters to the call to target a node with a specific architecture or even drive the parallel execution.

Our CI testing can be broken up logically into a few steps:

1. Get the code from GitHub.
2. Install the different decencies by calling npm install.
3. Run our run with the command mocha.
4. Clean up.

Those steps have an equivalent concept in Jenkins called stages. We are going to add them inside the node routing. Here is what the first stage will look like:

node { 
   stage 'Checkout' 
        checkout scm 
} 

This will tell Jenkins to get the code from source control. We previously stated when we created the job that it was a GitHub organization job, so Jenkins will know how to interpret that correctly.

In our second stage, we need to call npm install. Groovy doesn't natively understand language-specific features such as calling npm. In order to implement that, we will use the sh command, which will allow us to spawn a shell and run a command. Here is what our second stage looks like:

   stage 'Checkout' 
        checkout scm 
 
   stage 'Setup'
        sh 'npm install'

In our next stage, we are going to run Mocha. Below the Setup stage, add the following:

   stage 'Mocha test' 
        sh './node_modules/mocha/bin/mocha' 

Finally, we can proceed to clean up the repository with the following stage:

   stage 'Cleanup' 
        echo 'prune and cleanup' 
        sh 'npm prune' 
        sh 'rm node_modules -rf' 

The Jenkins file is now ready, it should look like this: http://bit.ly/2uDzkKm.

We can now commit our code and test it:

$ git add Jenkinsfile helloworld.js package.json test
$ git commit -m "Helloworld application"
$ git push 

This will create a remote branch called initial-branch. As the branch gets created, Jenkins will get a notification from GitHub about the change and will run the CI pipeline. In a matter of seconds, our test will run on Jenkins, which in turn will send the result back to GitHub. We observe it in this way:

1. Open GitHub in your browser and navigate to the helloworld project you created.
2. Click on Branch and select the initial-branch.
3. From that screen, click on New pull request, provide a title and a good description of the change you are making and, if possible, @mention other developers to get a thorough review of the change you are proposing.
4. Click on Create pull request and follow the steps to create a pull request. Once the pull request is created, you will be able to see how GitHub highlights that the pull requests passed all checks:
   

5. Optionally, you can click on the detail button, which will bring us back to the Jenkins job, where you can observe in more detail the execution of the job and its pipeline:
   
6. At that point, if you @mentioned other developers, they should get a notification and should look at the content of the pull request. Once reviewed and approved, the pull request can be merged. From that point on, when developers pull the master branch or rebase their branch, they will see your code.