Now that we have a build declared in our Jenkinsfile, we can build our first job. We'll start by clicking New Item in the top left corner, and create a new Multibranch Pipeline job called profile:

For our build, we'll need to edit the Branch Sources by adding the Project Repository and set our scan interval to run every minute. This is a public repository for me, so I don't need to attach any credentials. I'll use the default behaviors and property strategy:

After I click Scan, an immediate job will be run to discover branches on that repository. Although this screen looks just like a Jenkins build, its pass or fail status is entirely based on the ability to connect to your Git repository and find a Jenkinsfile on a branch. Let's check on our first build by returning to the home page:

Our splash page has our first build in it! The sun represents a passing build, indicating that each step in our build returned a positive exit status. On the far right of the build is a run build button, which is for if we'd like to run the build again. For now, click on the name profile and enter the details of the build. Because this is a multibranch pipeline, we'll also want to click the master branch to bring us into our status. You'll see that our build has run, and you can inspect each step of the way from this menu.

At this part of the phase, we have a set of commands that can be run on demand. To really make Continuous Integration work, we'll need to have our code test itself. Within our job, we can select View Configuration to come to the configuration page. We'll be setting our Build Triggers to poll the SCM every minute:

Once we've saved this configuration, Jenkins will automatically check our remote repository for changes every minute. We now have the simplest form of Continuous Integration: code that tests itself on every commit. With such a small amount of code coverage, our Continuous Integration pipeline doesn't provide us with much value, other than alerting us when we've created a malformed manifest.