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.