CI-CD_005_Git_with_Jenkins

Integrating Git with Jenkins

If we are dealing with some specific code based builds where the code doesn't need any modification can be directly used for a build. But in some cases the code need to be changed several times depending on the need. In such case the periodic builds need to have those modifications. We use SCM (Source Code Management) to overcome this situation. And instead of manually copying the code to the build we can integrate the repositories from the SCM tools with our Jenkins builds.

Configuration

• Global Settings In the Configure System page, the Git Plugin provides the following options:
  • Global Config user.name Value: if provided git config user.name is called before builds. This can be overridden by individual projects.
  • Global Config user.email Value: if provided git config user.email is called before builds. This can be overridden by individual projects.
  • Create new accounts base on author/committer's email: if checked, upon parsing of git change logs, new user accounts are created on demand for the identified committers / authors in the internal Jenkins database. The e-mail address is used as the id of the account.

Project Configuration

At the project level the Git Plugin is configured by selecting the Git option at the Source Code Management section.

The main section is Repositories where several can be configured. The information to provide include:

• The Repository URL, which is mandatory. The URL uses the same syntax as the git clone command. This can be a URL or a local file path. Note that for super-projects (repositories with submodules), only a local file path or a complete URL is valid.
  • The following are examples of valid git URLs.

    
    ssh://git@github.com/github/git.git
    
    git@github.com:github/git.git (short notation for ssh protocol)
    
    ssh://user@other.host.com/~/repos/R.git (to access the {repos/R.git repository in the user's home directory)
    https://github.com/github/git.git
    
    git://github.com/github/git.git
    

  • If the repository is a super-project, the location from which to clone submodules is dependent on whether the repository is bare or non-bare (i.e. has a working directory).
    • If the super-project is bare, the location of the submodules will be taken from .gitmodules.
    • If the super-project is not bare, it is assumed that the repository has each of its submodules cloned and checked out appropriately. Thus, the submodules will be taken directly from a path like ${SUPER_PROJECT_URL}/${SUBMODULE}, rather than relying on information from .gitmodules.
  • For a local URL/path to a super-project, git rev-parse --is-bare-repository is used to detect whether the super-project is bare or not.
  • For a remote URL to a super-project, the ending of the URL determines whether a bare or non-bare repository is assumed:
    • If the remote URL ends with /.git, a non-bare repository is assumed.
    • If the remote URL does NOT end with /.git, a bare repository is assumed.
• Credentials: Credentials to use to connect to the repository (unless anonymous access is allowed), using the Jenkins Credentials Management functionality. The type of credentials used depends on the underlying protocol. For SSH connections only private key authentication is supported.

The next section is Branches to Build in which several branch specifiers can be provided. For each of these specs, leaving it blank means that all branches will be examined for changes and built. The safest way is to use the refs/heads/ syntax. This way the expected branch is unambiguous. See the online help for more options.

A Repository Browser can also be configured, which adds links in "changes" views within Jenkins to an external system for browsing the details of those changes. The "Auto" selection attempts to infer the repository browser from other jobs, if supported by the SCM and a job with matching SCM details can be found, though it can also be selected manually.

Finally, the Git Plugin is extensible and the plugin itself as well as external plugins can provide Additional Behaviours to tweak the SCM configuration inside each particular project. Please refer to the online help of each of the additional options for further information.

Using Extra Repositories

Since GIT is a Distributed SCM, it is possible in the Advanced section to specify multiple repositories. You may wish to do this to, for example, pull all in-progress work from individual developers machines, and pre-test them before they are committed to a centralised repository - this way developers may get an early warning that a branch in progress may not be stable.

The GIT plugin will make reasonable attempts to try and pull submodule states from distributed repositories, with the proviso that this feature is not currently well supported within GIT itself.

CI-CD_004_Jenkins_Parameterized_Builds

Parameterized Builds

Sometimes, it is useful/necessary to have your builds take several "parameters." Consider the following use case:

• You set up a test job on Jenkins, and it accepts a distribution bundle as a parameter and perform tests against it. You want to have developers do local builds and let them submit builds for test execution on Jenkins. In such a case, your parameter is a zip file that contains a distribution.
• Your test suite takes so much time to run that in normal execution you can't afford to run the entire test cycle. So you want to control the portion of the test to be executed. In such a case, your parameter is perhaps a string token that indicates that test suite to be run.

These parameters are available as environment parameters. For example like we use the variables in a Shell script. Here we will have two parameters to be specified which are

1. Name

2. Default Value

If we are using any Shell script for our build and we have some variables need to be specified as arguments for the script then we need to keep the calling name of the variable as "Name" for the build and if we need to use default values for that we can specify those in the "Default Value" column. Or else we need to provide the value while running a build. Those values will be directly assigned to the variable parameters which will be used in the script.

For having our project to use parameters we need to do the following.

After the Project name and Description we'll have a check box "This build is parameterized". We need to check that box enabled to run parameterized builds. Now we need to provide the name and default value to be used within the project.

CI-CD_003-Jenkins-HipChat-Notifications

Notify your team about the build with status in HipChat

• To have this feature you need to install the HipChat Plugin.

    * Go to "Manage Jenkins"
    * Click on "Manage Plugins"
    * Click on "Available tab"
    * In the filter search for "HipChat"
    * Select "HipChat Plugin" and click on "Install without restart"

• Now restart your jenkins. You can do it depending on the way using jenkins.
  • If you are using jenkins directly then

      * service jenkins restart
  

  • If you are using jenkins through tomcat then

      * Login to your tomcat webui, go to "Manager App" and click on "Reload Jenkins"
          (or)
      * http://<HOSTNAME/IP>:8080/jenkins/restart
  

• Now you need to login to your HipChat web-ui and go to the room on which you have Admin access.

NOTE : To get admin access you need to create a room. You will be admin of the room that you've created.

    * Login to your hipchat account ( https://<my-hipchat>.hipchat.com/rooms/ )
        -- Ex: https://linux-library.hipchat.com/rooms/
    * Find and click on the room you've created.
    * Click on "Tokens"
    * Under the "Create new token" section provide a lable for your notification message.
    * Select "Send Notification" from "Scopes"
    * Click on Create.

    -- Above the "Create new token" section you'll get the Token with the lable you've give.

    * Copy that token.

    -- Now in the url after "tokens/" you'll notice a number that is your room number.

    * Copy that number.

• Now you need to configure these details in Jenkins.

    * Go to your jenkins home page click on "Manage Jenkins"
    * Click on "Configure System"
    * Go to "Global HipChat Notifier Settings" and provide the following settings
        * HipChat Server    : api.hipchat.com
        * Use v2 API        : yes
        * API Token     : <Paste your token here>
        * Room          : <Paste your room-id here>
    * Click Save

• Now in your project add the "Post-build Actions"

    * Click on "Add post-build action"
    * Select "HipChat Notifications" and provide the following details
        * Project Room      : <Paste your room-id here>
    * Under message templates provide the following values to get your build status notification.
        * Job started   :   ${JOB_NAME} #${BUILD_NUMBER}  ---  $STATUS  ---  ${URL}
        * Job completed :   ${JOB_NAME} #${BUILD_NUMBER}  ---  $STATUS - $DURATION  ---  ${URL}

• Now start the build and verify the build status notification in HipChat

CI-CD_001-Jenkins-Installation

Installation process of Jenkins

• Download and install latest version of JDK (Java 7 or newer version is recomended)
• Add the Jenkins repository to the yum repos, and install Jenkins from here.

    $ sudo wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo
    $ sudo rpm --import https://jenkins-ci.org/redhat/jenkins-ci.org.key
    $ sudo yum install jenkins

• Turn jenkins service at startup and restart the service

    # chkconfig jenkins on
    # service jenkins start

• Open your browser and hit the below URL to open Jenkins UI

    http://localhost:8080/

• It will now prompt for the Initial Admin password which is available in the below file

    /var/lib/jenkins/secrets/initialAdminPassword

Copy that password and paste in the field in the Jenkins web UI

• Now it will prompt for the installation of Jenkins Plugins. Go for the default.
• You are all set and the final step is that you need to create a Jenkins user.