Skip to main content

CI-CD_004 - 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.

Comments

Post a Comment

Popular posts from this blog

Troubleshooting Tomcat using Catalina log

Troubleshooting Tomcat using Catalina log We can get the  catalina  logs in  $CATALINA_HOME/logs Here we'll have a  catalina.out We can see some huge info in that log file. If we want to what exactly happens since the start of tomcat then we need to log that into a new file. By default we have log rotation enabled on this logs. For now let us stop tomcat and nullify the catalina.out file and then start tomcat to have some new info in the catalina.out # service tomcat stop # cd $CATALINA_HOME/logs # :> catalina.out (or) cat /dev/null > catalina.out # ll catalina.out -rw-r----- 1 root root 0 Feb 18 16:19 catalina.out # service tomcat start # ll catalina.out -rw-r----- 1 root root 17341 Feb 18 16:21 catalina.out We can see the log being written after the start of tomcat. Now we can notice the instance giving some information about the starting of tomcat, about the configuration for the startup, path of the servlet instance for which the log is re...
Post a Comment
Read more

Ansible Installation Steps Red Hat Enterprise Linux 7

Ansible is a simple IT automation engine that automates provisioning, configuration management, application deployment and many other IT needs.  Designed for multi-tier deployments, ansible models your IT infrastructure by describing how all of your systems interrelate, rather than just managing one system at a time. In this Article we are going to learn Ansible Installation Steps Red Hat Enterprise Linux 7 – RHEL 7. It uses no agents and no additional custom security infrastructure, so it’s easy to deploy – and most importantly, it uses a very simple language YAML that allow you to describe your automation jobs in a way that approaches plain English. Ansible Architecture Ansible works by connecting to your nodes and pushing out small programs, called “Ansible modules” to them. These programs are written to be resource models of the desired state of the system. Ansible then executes these modules using SSH Protocol, and removes them when finished. Your library of modul...
Post a Comment
Read more

RHVH 4.1 Installation Steps for Red Hat Virtualization Host

Red Hat Virtualization Host (RHVH 4.1) is installed using a special build ( Download Link )of Red Hat Enterprise Linux with only the packages required to host virtual machines. It uses an Anaconda installation interface based on the one used by Red Hat Enterprise Linux hosts, and can be updated through the Red Hat Virtualization Manager or via yum. Using the yum command is the only way to install additional packages and have them persist after an upgrade. In this article we are going to see RHVH 4.1 installation RHVH features a Web interface for monitoring the host’s resources and performing administrative tasks. Direct access to RHVH via SSH or console is not supported, so the Cockpit user interface provides a graphical user interface for tasks that are performed before the host is added to the Red Hat Virtualization Manager, such as configuring networking and deploying a self-hosted engine, and can also be used to run terminal commands via the  Tools > Terminal. Access t...
Post a Comment
Read more