Git Plugin

This plugin allows use of GIT as a build SCM. Git 1.3.3 or newer is required.

Plugin Information

Plugin ID git
Latest Release 2.2.5
Latest Release Date Oct 9, 2013
Sources Github
Support Eclipse Hudson Forum
Issue Tracking Eclipse Bugzilla


Common Tasks

  • If you are seeing output indicating Git could not clone, something like the output below, go to to the Hudson configuration settings (not the project settings, the global ones) and change the Git path to a fully qualified path (eg. not "git" but "/usr/bin/git" or wherever your Git binary is installed). You should also verify that the permissions are correct if you are doing a file system based clone.
Started by user anonymous
Checkout:workspace / C:\Documents and Settings\Administrator\.hudson\jobs\watir\workspace - hudson.remoting.LocalChannel@1a1f370
Last Build : #4
Checkout:workspace / C:\Documents and Settings\Administrator\.hudson\jobs\watir\workspace - hudson.remoting.LocalChannel@1a1f370
Cloning the remote Git repository
Cloning repository origin
$ git clone -o origin git://github.com/bret/watir.git "C:\Documents and Settings\Administrator\.hudson\jobs\watir\workspace"
Trying next repository
ERROR: Could not clone from a repository
FATAL: Could not clone
hudson.plugins.git.GitException: Could not clone
    at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:400)
    at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:358)
    at hudson.FilePath.act(FilePath.java:676)
    at hudson.FilePath.act(FilePath.java:660)
    at hudson.plugins.git.GitSCM.checkout(GitSCM.java:358)
    at hudson.model.AbstractProject.checkout(AbstractProject.java:833)
    at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:314)
    at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:266)
    at hudson.model.Run.run(Run.java:948)
    at hudson.model.Build.run(Build.java:112)
    at hudson.model.ResourceController.execute(ResourceController.java:93)
    at hudson.model.Executor.run(Executor.java:118)

* You may need to tell git who the user hudson is running as. In the latest versions of the plugin you can specify the user the project specific configuration for the git plugin. Alternatively on older Hudson installs on a Linux/Unix system edit the user's entry in /etc/passwd to set their login shell to /bin/bash instead of /bin/false. Then switch to that user which is probably tomcat6. Do this by using either of the following.

$ su tomcat6
$ sudo su tomcat6

Now cd to the directory where the clone hudson created is and use git config user.name and git config user.email to set the values.

$ cd /srv/hudson/jobs/project/workspace
$ git config user.email "some@email.com"
$ git config user.name "hudson"

When you are done, log off as the hudson user and change the login shell back to /bin/false

Advanced Features

Post Commit Hook

[Version 2.2.5 or higher]

To minimize the delay between a push and a build, it is recommended to set up the post-receive hook in the repository to poke Hudson when a new commit is made. To do this, add the following line in your hooks/post-receive where "URL of the Git repository" is the fully URL you use to clone this repository.curl http://yourserver/hudson/git/notifyCommit?url=<URL of the Git repository>[&branches=branch1[,branch2]*]

This will scan all the jobs that's configured to check out the specified URL, the optional branches, and if they are also configured with polling, it'll immediately trigger the polling (and if that finds a change worth a build, a build will be triggered in turn).  The polling is required to be configured on the job so that  jobs that are supposed to be kicked from changes in the source tree are triggered.

This allows a script to remain the same when jobs come and go inHudson . Or if you have multiple repositories under a single repository host application (such as Gitosis), you can share a single post-receive hook script with all the repositories. Finally, this URL doesn't require authentication even for secured Hudson, because the server doesn't directly use anything that the client is sending. It runs polling to verify that there is a change, before it actually starts a build.

When successful, this will return the list of projects that it triggered polling as a response.

Using Git, Hudson and pre-build branch merging

Continuous Integration tools such as Hudson are useful on projects as they give users early indication that a particular codebase is 'unstable' - and that if a developer checks it out, there will be trouble ahead (they won't be able to work on their own code, because someone else has broken something).

Unfortunately, by the time the build completes, this is often too late (particularly if the build cycle time is very long), as a developer has updated their working copy to the latest, unstable code in the repository and has begun work.

This can lead to the code base remaining unstable as developers tread on each others toes steadily fixing one thing, but breaking something else.

Some environments (e.g. TeamCity) attempt to fix this by making commits into SVN only 'really' happen once they have been tested. These kinds of 'delayed-commits' are problematic, because local SCM tools assume that commits will be immediately available, which can confuse them. In many ways this mechanism is a hack to get around the fact that branch management in SVN is very heavyweight.

Fortunately, with GIT and Hudson, you can achieve the same 'stable branches' with minimal effort.

Set up your hudson project, and leave the 'branch' field in the Git SCM blank. This will cause Hudson to consider any change on any branch for building.

Next, pick a particular branch name as the integration target in the 'Advanced' section - (e.g. 'master', or 'stable'), and select 'Merge before build'.

Select 'Push GIT tags back to origin repository' from the post-build actions (this is required to update your centralised git repo with the results of the build).

Now, developers should never commit directly to your integration branch (the 'master' or 'stable'). Instead, they should either use feature branches, or create new remote branches on commit (e.g : "git push origin HEAD:refs/heads/myNewFeature"). You could also set up your GIT repository to only accept commits onto the integration branch from Hudson.

You're done. Commits should now be automatically merged with the integration branch (they will fail if they do not merge cleanly), and built. If the build succeeds, the result of the merge will be pushed back to the remote git repository.

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.

Autogenerate submodule configurations

A common development pattern for many users is the use of a 'superproject' that aggregates a number of submodules. For example, ProjectA may have ComponentA, ComponentB and ComponentC. ComponentA is a shared library, and is set to use a particular revision (maybe on a branch called 'ProjectA' in case there are any changes). Usually, any changes to the project configuration require a commit to the ProjectA superproject.

However - there could be other changes happening on other branches of ComponentA (say to the development of the next version). Without someone generating commits into ProjectA to test these, any regressions or incompatibilities may be missed.

The autogenerate submodule configurations feature will create commits into ProjectA for all possible combinations of the branches present in the submodules that the project uses.

Labels:

plugin-scm plugin-scm Delete
tier1-plugin tier1-plugin Delete
Enter labels to add to this page:
Wait Image 
Looking for a label? Just start typing.
  1. Nov 17, 2009

    Kenneth P. Turvey says:

    I wrote a tutorial on getting hudson to work with git and grails.  It inclu...

    I wrote a tutorial on getting hudson to work with git and grails.  It includes all the information necessary to set up an integration server using git and hudson even if you aren't interested in grails development:

    http://www.electricsenator.net/2009/10/03/1254618530821.html

  2. Nov 18, 2009

    Graeme Simpson says:

    Is it possible to use credentials when accessing a git repository? Or certificat...

    Is it possible to use credentials when accessing a git repository? Or certificates?

    Thanks,
    Graeme

  3. Jan 01, 2010

    Chas Emerick says:

    Is there any way to get the git plugin to checkout ref names instead of the sha'...

    Is there any way to get the git plugin to checkout ref names instead of the sha's associated with remote refs? Not being on a branch in the course of a build is causing issues (for at least two of us) in conjunction with the M2 Release Plugin:

    Can’t get automated release working with Hudson + Git + Maven Release Plugin

    1. Feb 02, 2010

      Chas Emerick says:

      This issue has been resolved for me as of v0.8.0 of the git plugin.  See my...

      This issue has been resolved for me as of v0.8.0 of the git plugin.  See my comment below.

      1. Mar 17, 2010

        David Antliff says:

        Really? I'm using 0.8 (by using the Hudson plugin upgrader) and still seeing Hud...

        Really? I'm using 0.8 (by using the Hudson plugin upgrader) and still seeing Hudson check out a specific SHA-1 rather than a reference:

        [workspace] $ git checkout -f 2904dc785ef11727aab604b2119bfbb4341a24bc
        

        even though I specified "origin/myBranch" in the Branch Specifier field. This detaches HEAD and makes it impossible (or very hard at least) for a subsequent build script to know what branch it's building on.

  4. Jan 06, 2010

    Brad Robertson says:

    I can't get Hudson to merge into the master branch. It always ends up in *no br...

    I can't get Hudson to merge into the master branch. It always ends up in *no branch, which is no good to me as I want to push master to another remote repo as a deploy.
    I've set the following:
    refspec: +refs/heads/master:refs/remotes/origin/master
    branch to build: */master
    branch to merge to: master

    The Git logs show it fetching the latest, then for some reason checking out the previous version with the sha, which puts it into *no branch. Then it does a git merge with the latest, still on *no branch. I've included the logs below.

    I don't think this is the correct behavior given that I specify that I want to merge to the master branch. Thoughts? Bug?

    Git logs from hudson:
    git fetch /home/git/repositories/my_repo.git +refs/heads/master:refs/remotes/origin/master
    git ls-tree HEAD
    git rev-parse master
    git checkout -f old_rev_sha here's where it switches branches
    git merge new_rev_sha

    1. Jan 08, 2010

      Chas Emerick says:

      I don't know if this is a bug, but +1 that this isn't correct behaviour IMO (see...

      I don't know if this is a bug, but +1 that this isn't correct behaviour IMO (see my comment directly above yours).

      1. Jan 09, 2010

        Brad Robertson says:

        ya i read that. I'm also confused as to why it's using sha's, especially when t...

        ya i read that. I'm also confused as to why it's using sha's, especially when the plugin allows you to specify the ref you want and the branch to merge to.

        I personally do think it's a bug if you are specifying the branch to merge to and the fetched code is not merged to that branch

        1. Feb 02, 2010

          Chas Emerick says:

          I upgraded to v0.8.0 of the git plugin, and have been able to perform a maven re...

          I upgraded to v0.8.0 of the git plugin, and have been able to perform a maven release using the Maven release plugin, and have the results successfully pushed back to master.

          v0.8.0 appears to add a "Merge options" section (in the advanced tab under the SCM section of the project config).  I put "origin" in 'name of repository' and "master" in 'branch to merge to', and the push went swimmingly.

          1. Feb 11, 2010

            Brad Robertson says:

            Merge options were definitely available in 0.73. I mentioned above that I put i...

            Merge options were definitely available in 0.73. I mentioned above that I put in "master" as "branch to merge to" in my settings and it still didn't work. I haven't upgraded to 0.8 though so I'll check it out when I get a chance. I don't know how this can't be documented anywhere though.

            1. Mar 16, 2010

              David Antliff says:

              Brad: did you have any success with 0.8 in this respect? I'm seeing Hudson conti...

              Brad: did you have any success with 0.8 in this respect? I'm seeing Hudson continue to check out the specific SHA rather than the branch reference, and therefore detach the HEAD.

              1. Mar 17, 2010

                Brad Robertson says:

                To be honest, I haven't looked at this in quite some time, i'm working on a few ...

                To be honest, I haven't looked at this in quite some time, i'm working on a few projects so i've been fairly busy. I'll keep you posted when I find the time to see if this has been fixed for me.

  5. Jan 11, 2010

    Anonymous ultimo says:

    Problems with new 0.8 version under windows. It looks very good and the new inf...

    Problems with new 0.8 version under windows.

    It looks very good and the new information about changed files is great but scm polling doesn't work anymore

    1. Feb 08, 2010

      J. Longman says:

      I'm also having problems, but I'm not using windows: Feb 8, 2010 11:51:03 AM h...

      I'm also having problems, but I'm not using windows:

      Feb 8, 2010 11:51:03 AM hudson.triggers.SCMTrigger$Runner runPolling
      SEVERE: Failed to record SCM polling
      java.lang.NullPointerException
      	at hudson.plugins.git.GitSCM.pollChanges(GitSCM.java:254)
      	at hudson.model.AbstractProject.pollSCMChanges(AbstractProject.java:1067)
      	at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:319)
      	at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:346)
      	at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118)
      	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
      	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
      	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
      	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
      	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
      	at java.lang.Thread.run(Thread.java:619)
      
      Solved by adding executors to my master
  6. Mar 16, 2010

    David Antliff says:

    Is there an inconsistency here? This page says 0.8 is the Latest Release, but th...

    Is there an inconsistency here? This page says 0.8 is the Latest Release, but the download link to the .hpi file is pointing at 0.7.3.

    What is the download link to the 0.8 hpi please, as I need to archive this file for static installation at my site.

  7. Mar 27, 2010

    Evgeny Goldin says:

    Hi, I have a problem with latest Hudson v1.352 and Git plugin v0.8.1. After fet...

    Hi,

    I have a problem with latest Hudson v1.352 and Git plugin v0.8.1.
    After fetching successfully Git sources - Maven fails with NPE

    java.lang.NullPointerException
    	at java.util.Hashtable.put(Hashtable.java:394)
    	at java.util.Hashtable.putAll(Hashtable.java:466)
    	at hudson.maven.MavenBuilder.call(MavenBuilder.java:156)
    	at hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:688)
    	at hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:632)
    	at hudson.remoting.UserRequest.perform(UserRequest.java:114)
    	at hudson.remoting.UserRequest.perform(UserRequest.java:48)
    	at hudson.remoting.Request$2.run(Request.java:270)
    	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
    	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
    	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
    	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    	at java.lang.Thread.run(Thread.java:619)
    

    Here's the full log and job's configuration

    Git plugin passes null value for GIT_BRANCH environment variable,
    which later fails in MavenBuilder.java:156 when Maven plugin calls
    System.getProperties().putAll(systemProps)

    Here's a debugger screenshot.

    1. Mar 27, 2010

      Evgeny Goldin says:

      Fixed it by specifying "master" as default branch, not empty and not "**...

      Fixed it by specifying "master" as default branch, not empty and not "**".
      Posted it in my blog as well.

  8. Apr 02, 2010

    Mark Moore says:

    I'm hoping this is the right place to post this question...  It looks like ...

    I'm hoping this is the right place to post this question...  It looks like the Git plugin simply issues a git fetch origin master (or something reasonably similar).  I want to force a clean before fetching.  specifically "git -fx clean"  Does anyone know how to make this happen?  I could add this to the build commands, but that seems a little wrong.

    Help!

    -Mark

    1. Apr 02, 2010

      David Antliff says:

      What we do is issue the 'git clean' command as one of the first things the build...

      What we do is issue the 'git clean' command as one of the first things the build script (stored within the repository) executes. You could add it to the build command list if you wanted to, I don't think it's wrong. Hudson is just responsible for cloning/updating.

      I just wish it checked out a ref instead of a commit, or at least set an environment variable to the specified branch name :)

  9. May 06, 2010

    Mik Lernout says:

    This page should probably mention that the Git plugin relies on a recent version...

    This page should probably mention that the Git plugin relies on a recent version of the Git binaries (at least 1.7?).

  10. Jun 15, 2010

    Ian Eure says:

    Same problem here with builds always starting from a detached HEAD. I'm using th...

    Same problem here with builds always starting from a detached HEAD. I'm using the most recent version of the plugin, 0.8.3.

    My config is:

    URL of repository: git://github.com/simplegeo/libmemcached.git
    Name of repository: origin
    Refspec: +refs/heads/*:refs/remotes/origin/*
    
    Branches to build: master
    
    Merge before build: Yes
    Name of repository: origin
    Branch to merge to: master
    
    Clean after checkout: Yes
    Choosing strategy: Default
    Repository browser: (Auto)
    

    These are the git commands that get run:

    Checkout:libmemcached-test / /home/pubhudsonslave/workspace/libmemcached-test - hudson.remoting.Channel@581ea2:pubhudsonslave
    Using strategy: Default
    Last Built Revision: Revision 13e70eabe93822d0ce7fceee6ebcbbd490b19a76 (origin/master)
    Checkout:libmemcached-test / /home/pubhudsonslave/workspace/libmemcached-test - hudson.remoting.LocalChannel@135c7da7
    GitAPI created
    Fetching changes from the remote Git repository
    Fetching upstream changes from git://github.com/simplegeo/libmemcached.git
    [libmemcached-test] $ git fetch -t git://github.com/simplegeo/libmemcached.git +refs/heads/*:refs/remotes/origin/*
    [libmemcached-test] $ git ls-tree HEAD
    [libmemcached-test] $ git tag -l master
    [libmemcached-test] $ git rev-parse origin/master
    Commencing build of Revision 13e70eabe93822d0ce7fceee6ebcbbd490b19a76 (origin/master)
    GitAPI created
    Checking out Revision 13e70eabe93822d0ce7fceee6ebcbbd490b19a76 (origin/master)
    [libmemcached-test] $ git checkout -f 13e70eabe93822d0ce7fceee6ebcbbd490b19a76
    [libmemcached-test] $ git tag -a -f -m "Hudson Build #7" hudson-libmemcached-test-7
    Recording changes in branch origin/master
    [libmemcached-test] $ git log --pretty=format:%H 13e70eabe93822d0ce7fceee6ebcbbd490b19a76..13e70eabe93822d0ce7fceee6ebcbbd490b19a76
    Cleaning workspace
    [libmemcached-test] $ git clean -fdx
    Finished: SUCCESS
    

    It's not merging anything, and it's still checking out a SHA-1 instead of a symbolic branch name. What gives?

  11. Jun 18, 2010

    Alexander Sparkowsky says:

    I'm trying to figure out how the tags generated by the plugin for each build are...

    I'm trying to figure out how the tags generated by the plugin for each build are pushed back to the origin repository.

    The text above mentions an option called 'Push GIT tags back to origin repository' but I'm not able to find it.

    So how do I get the plugin pushing the tags for each build to the upstream repo?

  12. Jun 25, 2010

    ITDude says:

    Folks, I'm experiencing problems setting up the GIT Plugin on a Debian system us...

    Folks, I'm experiencing problems setting up the GIT Plugin on a Debian system using a SSH key for authentication and was hoping somebody has had some experience with this setup who could offer some pointers.

    I believe the problem is that it fails to find the key and thus present it to the GIT server. I've installed a valid key into the /usr/share/tomcat5.5/.ssh directory which is the home of the tomcat55 user but it fails with a ssh-askpass error.

    Now I'm guessing that the process is running as the tomcat55 user but I could be wrong as looking at the logs below you can see that it is attempting to fetch to the /home/hudson directory. What's confusing about this is that the system does not have a user 'hudson' and in the System Information section of the web interface the enveronment looks as though it's running as the root user.

    Here's the log output;

    ------------------
    Started by user ITDude
    Checkout:workspace / /home/hudson/jobs/TestHudson/workspace - hudson.remoting.LocalChannel@f74f6ef
    Using strategy: Default
    Checkout:workspace / /home/hudson/jobs/TestHudson/workspace - hudson.remoting.LocalChannel@f74f6ef
    GitAPI created
    Fetching changes from the remote Git repository
    Fetching upstream changes from git@git.mycomp.com:test_hudson.git
    [workspace] $ /usr/bin/git fetch -t git@git.mycomp.com:test_hudson.git +refs/heads/:refs/remotes/origin/
    No protocol specified

    (ssh-askpass:13369): Gtk-WARNING **: cannot open display: :0.0
    Permission denied, please try again.
    No protocol specified

    (ssh-askpass:13370): Gtk-WARNING **: cannot open display: :0.0
    Permission denied, please try again.
    No protocol specified

    (ssh-askpass:13371): Gtk-WARNING **: cannot open display: :0.0
    Permission denied (publickey,password).
    fatal: The remote end hung up unexpectedly
    ERROR: Problem fetching from origin / origin - could be unavailable. Continuing anyway
    ERROR: Nothing to do
    Finished: FAILURE
    ========================

    The key is definitely valid as I've tested it with a manual connection.

  13. Jun 25, 2010

    Dale Hards says:

    Hello, I'm having difficulties getting the git plugin to fetch from the reposit...

    Hello,

    I'm having difficulties getting the git plugin to fetch from the repository. In the job's configuration I have provided:

    URL of repository: git@git.mydomain.com:test_hudson.git

    • which as far as I know is correct.

    Name of repository: origin/master

    • I have two choices. My repository is remote and according to Git Extensions on my Windows machine where I am pushing code to the central repository the repository is either origin/HEAD or origin/master - I have tried both.

    Refspec: I leave this blank and it generates the following: +refs/heads/:refs/remotes/origin/master/

    I have also provided the Branches to build: master

    I have tried many different combinations of settings, and each one gives a different error message, but none of them are ever getting to the point where Ant builds my simple Java project. On the above settings, I get the following log:

    ***

    Started by user daleh
    Checkout:workspace / /home/hudson/jobs/TestHudson/workspace - hudson.remoting.LocalChannel@3219ab8d
    Using strategy: Default
    Checkout:workspace / /home/hudson/jobs/TestHudson/workspace - hudson.remoting.LocalChannel@3219ab8d
    GitAPI created
    Fetching changes from the remote Git repository
    Fetching upstream changes from git@git.mydomain.com:test_hudson.git
    [workspace] $ /usr/bin/git fetch -t git@git.mydomain.com:test_hudson.git +refs/heads/:refs/remotes/origin/master/
    error: unable to resolve reference refs/remotes/origin/master/master: Not a directory
    From git@git.mydomain.com:test_hudson
    ! [new branch] master -> origin/master/master (unable to update local ref)
    error: some local refs could not be updated; try running
    'git remote prune git@git.mydomain.com:test_hudson.git' to remove any old, conflicting branches
    ERROR: Problem fetching from origin/master / origin/master - could be unavailable. Continuing anyway
    [workspace] $ /usr/bin/git tag -l master
    [workspace] $ /usr/bin/git rev-parse origin/master/master
    ERROR: Nothing to do
    Finished: FAILURE

    ***

    As for needing to remove any "old conflicting branches", I have none. This is a simple project with no conflicting branches.

    Thanks in advance for any help provided

    1. Jun 27, 2010

      Dale Hards says:

      This has now been resolved through the mailing list. The problem was that origin...

      This has now been resolved through the mailing list. The problem was that origin/master is a branch not a repository. I needed to leave the repository blank (letting it be automatically set as "origin"), and supplying "origin/master" in the "build branch" setting. This fixed the problem fine.

  14. Jul 13, 2010

    Adam Szecowka says:

    Hello, I have repoA and repoB, and i want clone repoA to directory for example w...

    Hello,
    I have repoA and repoB, and i want clone repoA to directory for example workspace/myJob/A and clone repoB to workspace/myJob/B. Is it possible with this plugin ?

  15. Jul 26, 2010

    Dave Abrahams says:

    Having Serious Submodule Problems. I confess that I don't understand what the d...

    Having Serious Submodule Problems. I confess that I don't understand what the documentation above about automatic submodule handling is trying to convey about what Hudson is doing, but whatever it is, it seems to be wrong. I'm content to do the git submodule init / git submodule update myself if necessary. Log below; can you please help? Thanks!

    Started by user dave
    Checkout:workspace / /var/lib/hudson/jobs/Boost/workspace - hudson.remoting.LocalChannel@3faa7a6a
    Using strategy: Default
    Last Built Revision: Revision 9fc9270750b81ec49fb96ee7b37fde5547da67c7 (origin/master)
    Checkout:workspace / /var/lib/hudson/jobs/Boost/workspace - hudson.remoting.LocalChannel@3faa7a6a
    GitAPI created
    Cloning the remote Git repository
    Cloning repository origin
    $ git clone -o origin git://gitorious.org/ryppl/boost.git /var/lib/hudson/jobs/Boost/workspace
    Fetching upstream changes from git://gitorious.org/ryppl/boost.git
    [workspace] $ git fetch -t git://gitorious.org/ryppl/boost.git +refs/heads/:refs/remotes/origin/
    [workspace] $ git ls-tree HEAD
    GitAPI created
    Fetching upstream changes from git://gitorious.org/ryppl/boost.git/cmake/.git
    [cmake] $ git fetch -t git://gitorious.org/ryppl/boost.git/cmake/.git +refs/heads/:refs/remotes/origin/
    fatal: protocol error: expected sha/ref, got '
    ----------------------------------------------
    Cannot find repository /ryppl/boost.git/cmake/.git
    ----------------------------------------------'
    ERROR: Problem fetching from origin - could be unavailable. Continuing anyway
    [workspace] $ git submodule init
    [workspace] $ git submodule update
    [workspace] $ git tag -l master
    [workspace] $ git rev-parse origin/master
    Commencing build of Revision 9fc9270750b81ec49fb96ee7b37fde5547da67c7 (origin/master)
    GitAPI created
    Checking out Revision 9fc9270750b81ec49fb96ee7b37fde5547da67c7 (origin/master)
    [workspace] $ git checkout -f 9fc9270750b81ec49fb96ee7b37fde5547da67c7
    [workspace] $ git submodule init
    [workspace] $ git submodule sync
    Fetching upstream changes from git://gitorious.org/ryppl/boost.git
    [workspace] $ git fetch -t git://gitorious.org/ryppl/boost.git +refs/heads/:refs/remotes/origin/
    [workspace] $ git ls-tree HEAD
    GitAPI created
    Fetching upstream changes from git://gitorious.org/ryppl/boost.git/cmake/.git
    [cmake] $ git fetch -t git://gitorious.org/ryppl/boost.git/cmake/.git +refs/heads/:refs/remotes/origin/
    fatal: protocol error: expected sha/ref, got '
    ----------------------------------------------
    Cannot find repository /ryppl/boost.git/cmake/.git
    ----------------------------------------------'
    ERROR: Problem fetching from origin - could be unavailable. Continuing anyway
    [workspace] $ git submodule update
    [workspace] $ git tag -a -f -m "Hudson Build #4" hudson-Boost-4
    Recording changes in branch origin/master
    [workspace] $ git whatchanged --no-abbrev -M --pretty=raw 9fc9270750b81ec49fb96ee7b37fde5547da67c7..9fc9270750b81ec49fb96ee7b37fde5547da67c7
    Triggering default
    Finished: FAILURE

    1. Aug 06, 2010

      Vincent Driessen says:

      The error occurs directly after the "git ls-tree HEAD" command. Assuming a defau...

      The error occurs directly after the "git ls-tree HEAD" command. Assuming a default Git repo setup, HEAD refers to "master" at that stage. I think the output of that process is scanned and each entry that has mode flag 160000 (= submodule commit) is filtered out and processed accordingly.

      How it detects and fetches from the submodule URL? I have no clue at all, but I know it's wrong.

      Furthermore, I have a branch called "develop" that does NOT have a submodule commit, but my master does. Even it I configure a Hudson job to fetch from branch "develop", it still uses "git ls-tree HEAD" to scan/parse for submodules, before switching to "develop", also breaking those builds. I've filed this as a bug on the Git plugin issue list (see http://github.com/magnayn/Hudson-GIT-plugin/issues#issue/4).

  16. Aug 25, 2010

    Miraj Hasnaine Tafsir says:

    There is no included region feature for GIT. If there are some few regions to be...

    There is no included region feature for GIT. If there are some few regions to be participated in the build I think its not a good idea to have so many excluded regions to be listed. Included region will be doing better in this case.

    1. Sep 02, 2010

      Patrick Renaud says:

      I second that. Did you submit a JIRA for this yet?

      I second that. Did you submit a JIRA for this yet?

  17. Sep 14, 2010

    John Firebaugh says:

    I would like to use the "pre-build branch merging" features mentioned, but I wan...

    I would like to use the "pre-build branch merging" features mentioned, but I want hudson to either:

    • accept only fast-forward merges, or
    • rebase instead of merge (ignoring branches that don't rebase cleanly)

    I work in an environment where `git pull --rebase` is preferred, so I don't want hudson cluttering up the commit history with its own merge commits.

    Is there any way to accomplish this?

  18. Oct 19, 2010

    David Antliff says:

    I have upgraded the git plugin from 0.8 to 1.1 (under Hudson 1.380) and I'm seei...

    I have upgraded the git plugin from 0.8 to 1.1 (under Hudson 1.380) and I'm seeing a new problem with submodules and tags. It appears that in some circumstances (exact ones not yet known, I'm still investigating) the tags within a submodule are fetched into the main (i.e. parent) clone. This has build-terminating results in my case, but is probably just weird for most people.

    In this, there's a submodule called 'build-scripts' that is bound to the path 'build' within the parent clone (DAC16_v2):

    Cloning the remote Git repository
    Cloning repository origin
    $ c:\cygwin\bin\git.exe clone -o origin git://gitsj/git/sp/modules/DAC_16v2.git C:\hudson\jobs\DAC_16v2-release-1.0\workspace
    Fetching upstream changes from git://gitsj/git/sp/modules/DAC_16v2.git
    [workspace] $ c:\cygwin\bin\git.exe fetch -t git://gitsj/git/sp/modules/DAC_16v2.git +refs/heads/*:refs/remotes/origin/*
    [workspace] $ c:\cygwin\bin\git.exe rev-parse origin/release-1.0
    Commencing build of Revision 2301bed44fa71fb71b60507ae534bcff4bbee324 (origin/release-1.0)
    GitAPI created
    Checking out Revision 2301bed44fa71fb71b60507ae534bcff4bbee324 (origin/release-1.0)
    [workspace] $ c:\cygwin\bin\git.exe checkout -f 2301bed44fa71fb71b60507ae534bcff4bbee324
    [workspace] $ c:\cygwin\bin\git.exe submodule init
    [workspace] $ c:\cygwin\bin\git.exe submodule sync
    Fetching upstream changes from git://gitsj/git/sp/modules/DAC_16v2.git
    [workspace] $ c:\cygwin\bin\git.exe fetch -t git://gitsj/git/sp/modules/DAC_16v2.git +refs/heads/*:refs/remotes/origin/*
    [workspace] $ c:\cygwin\bin\git.exe ls-tree HEAD
    Trying to fetch build into C:\hudson\jobs\DAC_16v2-release-1.0\workspace\build
    GitAPI created
    Fetching upstream changes from git://gitsj/git/sp/tools/build-scripts.git
    [build] $ c:\cygwin\bin\git.exe fetch -t git://gitsj/git/sp/tools/build-scripts.git +refs/heads/*:refs/remotes/origin/*
    warning: no common commits
    From git://gitsj/git/sp/tools/build-scripts  + f94c6f4...ee4c0c9 master     -> origin/master  (forced update)
     * [new branch]      ngo-dependencies -> origin/ngo-dependencies
     * [new tag]         released-1.0 -> released-1.0
     * [new tag]         released-1.1 -> released-1.1
     * [new tag]         released-1.2 -> released-1.2
     * [new tag]         released-1.3 -> released-1.3
     ...
    [workspace] $ c:\cygwin\bin\git.exe submodule update
     ...
    

    You can see around the "warning: no common commits" that the plugin is fetching from the submodule (build-scripts.git)!

    Trying to fetch build into C:\hudson\jobs\DAC_16v2-release-1.0\workspace\build
    ...
    Fetching upstream changes from git://gitsj/git/sp/tools/build-scripts.git

    That's not right. Those new branches and tags are in the submodule but are being fetched into the parent. It shouldn't be doing this.

    EDIT: new info - existing Hudson jobs from pre-upgrade work fine and the submodule tags are not 'merged' with the parent. But if I 'clear workspace' and rebuild any of them, they exhibit the incorrect behaviour noted above.

    1. Oct 19, 2010

      David Antliff says:

      How do I get 'permission' to create a new JIRA issue? I signed up for a dev.java...

      How do I get 'permission' to create a new JIRA issue? I signed up for a dev.java.net account but when I click on the "create issue" link at the top of this page, JIRA tells me:

      Errors

      • pid: You do not have permission to create issues in this project.
    2. Nov 01, 2010

      David Antliff says:

      Ok, this is a pretty major bug and is also a regression as older versions do not...

      Ok, this is a pretty major bug and is also a regression as older versions do not have this problem. I want to file a proper bug report but (as above) I get a permission error. So what can I do to help this bug get fixed?

    3. Nov 11, 2010

      David Antliff says:

      Once again, this is a major bug and needs to be addressed. Since nobody has told...

      Once again, this is a major bug and needs to be addressed. Since nobody has told me how I can file a proper bug report, what am I supposed to do?

      BTW I found a workaround - using a Cygwin shell in the workspace directory, I did:

        $ git tag | xargs git tag -d

        $ git fetch --tags

      This restored all of the tags that are meant to be there, and did not reintroduce those that were wrong. Subsequent builds now behave properly, but it is still a problem for new build jobs, especially as our Hudson server filesystem is not accessible to users.

  19. Nov 02, 2010

    Doug Reiland says:

    I want to setup trigger on commits to branches, merge branch to integration bran...

    I want to setup trigger on commits to branches, merge branch to integration branch, build, and push changes back to integration branch on remote.
    I have it mostly working, but when the git plugin pushes the merge back, it triggers another build.

    I tried change the refspec option to something like:
    +refs/for/:refs/remotes/foo-repo/

    and developer pushes changes to refs/for/<somename>, but didn't help.
    Under the "git publisher" options, branch to push is refs/heads/golden

  20. Nov 02, 2010

    Doug Reiland says:

    Maybe somebody can give me step by step instructions. I want hudson to trigger o...

    Maybe somebody can give me step by step instructions.
    I want hudson to trigger on changes, I have this working with post-receive hook in "global repository"
    I want the development to push changes to temporary branches in "global repository", say like:
    git push "global repository" HEAD:refs/heads/username/fixes

    I want hudson to trigger, merge the changes into the "golden" branch from "global repository", build, and on success push changes back to golden branch on "global repository"

    In addition, I want to delete the temporary branch in "global repository" as a post build step.
    Ideally, I don't want hudson's push to golden to trigger another build.

    Thanks!

  21. Nov 02, 2010

    Doug Reiland says:

    Also, what is the best way to get the name of the branch that cause the trigger ...

    Also, what is the best way to get the name of the branch that cause the trigger event? Are there environment variables set by the plugin?
    In the post-build script plugin, I want to do something like: git push <url> :$GIT_BRANCH to delete the branch

  22. Nov 22, 2010

    Patrick Renaud says:

    The latest release seems to be 1.1.3 but there is no corresponding entry for it ...

    The latest release seems to be 1.1.3 but there is no corresponding entry for it in the Changelog section. How can we find out what's new in 1.1.3?

  23. Jan 31, 2011

    Joe Hansche says:

    The logic behind "Merge before build" options appears to be incorrect, if the "R...

    The logic behind "Merge before build" options appears to be incorrect, if the "Refspec" is non-standard (e.g., default is refs/heads/*:refs/remotes/origin/* .. this would be replaced with $GERRIT_REFSPEC when using the Gerrit Trigger plugin).  The git plugin only performs a fetch on $GERRIT_REFSPEC, but later, when figuring out which branch to merge to, it does not fetch the ref that represents the branch I want to merge to.  I'm trying to make the Gerrit Trigger build confirm that the patch set is able to 1) merge properly with "master", and 2) passes any other tests I want to confirm.  If I don't specify the Merge option, Hudson will simply checkout the sha1 hash of the $GERRIT_REFSPEC, which will always contain the code that the developer had locally when committing -- however, that code might have been out of date with master, and thus will not be able to merge properly.  My config:

    URL: ssh://gerrit:29418/Project/Name
    Repo Name: gerrit
    Refspec: $GERRIT_REFSPEC
    
    Checkout/merge to local branch: master
    Merge before build: Yes
      - Name of repo: gerrit
      - Branch to merge to: master
    

    The git plugin performs these commands:

    Fetching changes from the remote Git repository
    Fetching upstream changes from ssh://gerrit:29418/Project
    [gerrit-verify-build] $ /usr/bin/git fetch -t ssh://gerrit:29418/Project refs/changes/01/101/1
    [gerrit-verify-build] $ /usr/bin/git ls-tree HEAD
    [gerrit-verify-build] $ /usr/bin/git rev-parse FETCH_HEAD
    Commencing build of Revision 7e2748e4312146f1f3b090ec3d9c70a7acfc16af (master)
    GitAPI created
    Merging Revision 7e2748e4312146f1f3b090ec3d9c70a7acfc16af (master) onto master
    [gerrit-verify-build] $ /usr/bin/git rev-parse gerrit/master
    [gerrit-verify-build] $ /usr/bin/git checkout -f f5f1543886606eee0ab258316c276e21ba5f13a2
    [gerrit-verify-build] $ /usr/bin/git branch -a
    [gerrit-verify-build] $ /usr/bin/git rev-parse master
    [gerrit-verify-build] $ /usr/bin/git rev-parse remotes/gerrit/master
    [gerrit-verify-build] $ /usr/bin/git branch -D master
    [gerrit-verify-build] $ /usr/bin/git checkout -b master f5f1543886606eee0ab258316c276e21ba5f13a2
    [gerrit-verify-build] $ /usr/bin/git merge 7e2748e4312146f1f3b090ec3d9c70a7acfc16af
    Warning : There are multiple branch changesets here
    [gerrit-verify-build] $ /usr/bin/git rev-parse FETCH_HEAD
    [gerrit-verify-build] $ /usr/bin/git log -1 --pretty=format:%P 7e2748e4312146f1f3b090ec3d9c70a7acfc16af
    [gerrit-verify-build] $ /usr/bin/git whatchanged --no-abbrev -M --pretty=raw e79d78e39c67b324f95f604ba8e5fbe49232882d..7e2748e4312146f1f3b090ec3d9c70a7acfc16af
    

    The problem is that it only fetches the $GERRIT_REFSPEC (so it grabs the gerrit patch correctly), but it never fetches "remotes/gerrit/master". Therefore, the merge to master (in this case, f5f15438) is merging to an old revision of master, not the latest revision.

    What I would expect it to do is:

    $ git fetch -t $GERRIT_REFSPEC
    $ git rev-parse FETCH_HEAD               # (call it 2222222)
    $ git fetch gerrit master
    $ git rev-parse [remotes/]gerrit/master  # (call it 1111111)
    $ git checkout -D master
    $ git checkout -b master 1111111
    $ git merge 2222222
    $ .. continue
    

    The point being, it should fetch both the configured "Refspec" ($GERRIT_REFSPEC), and the configured "Merge to branch .." ref, before trying to merge the two. By only fetching the main "Refspec", it's not able to checkout the correct/most recent "master" prior to the merge.

    Another issue I have seen is that it doesn't reset the workspace. That is, I don't want the "Merge" to persist in the workspace after the merge attempt.. If the Gerrit review is approved, it will get merged by gerrit. My purpose for using the merge option is to just "check" that it merges cleanly, but not to persist the result in any other location. When I check the Hudson workspace, I'm seeing multiple local commits that shouldn't be there, which seems strange to me, because I thought it would reset to a clean state that matches the remote. E.g.:

    $ git fetch gerrit
    $ git reset --hard remotes/gerrit/master
    $ .. continue with fetching/merging/etc
    
  24. Feb 02, 2011

    Damon New says:

    Does this plugin support the "domain\username" format in the Git ssh url? For ex...

    Does this plugin support the "domain\username" format in the Git ssh url? For example:

    ssh://mydomain\dnew@dev2/var/local/git/myrepo.git

    The plugin seems to always replace backslashes with forward slashes. I tried escaping the backslash with a double and tripple backslash but it converts them all to forward slashes.

  25. May 19, 2011

    Patrick O'Meara says:

    I have just updated hudson and Git Plugin to the lastest versions, still getting...

    I have just updated hudson and Git Plugin to the lastest versions, still getting this Host Key Verification issue, only on submodules, the main project checkouts fine

    Trying to fetch system into /var/lib/hudson/jobs/project/workspace/system
    Fetching upstream changes from git@gitserver:system
    Problem fetching from submodule system - could be unavailable. Continuing anyway
    FATAL: Error performing command: git submodule update
    Command "git submodule update" returned status code 1: Initialized empty Git repository in /var/lib/hudson/jobs/project/workspace/system/.git/
    Host key verification failed.
    fatal: The remote end hung up unexpectedly
    Clone of 'git@gitserver:system' into submodule path 'system' failed

    hudson.plugins.git.GitException: Error performing command: git submodule update
    Command "git submodule update" returned status code 1: Initialized empty Git repository in /var/lib/hudson/jobs/project/workspace/system/.git/
    Host key verification failed.
    fatal: The remote end hung up unexpectedly
    Clone of 'git@gitserver:system' into submodule path 'system' failed

    any ideas?

  26. Nov 07, 2011

    Mohammad Arifur Rahman says:

    I apologise first for not knowling all technical terms correctly. We have a Gra...

    I apologise first for not knowling all technical terms correctly.

    We have a Grails project for which we use GIT. Normally we use msysgit in our windows machine as GIT client. I know it somehow reads my public key stored in my profile directory and uses that while communicating with server.

    I created a job in hudson with that project. Eveytime while hudson was trying to produce a build, I could see from console, it was getting stuck at:

    Checkout:workspace / [MY LOCAL WORKSPACE LOCATION] - hudson.remoting.LocalChannel@1091f09

    I finally understood that it was getting stuck asking for some fingerprint confirmation, which I could easily proceed with if I had invoked GIT checkout from command line. I found no easy solution for this, so today, I am moving to CentOS 6.

    In a nutshell, my 12 hours research suggests, the hudson GIT plugin is not mature enough yet on Windows for repositories with ssh securities. Or some easy configuration parameters should be added so that dummies like me can get benefited. ;-)

    Nice work though. Cheers.

  27. Mar 22, 2013

    Jay says:

    Hi Everyone, Was wondering if anybody had encounter the same issue that I had r...

    Hi Everyone,

    Was wondering if anybody had encounter the same issue that I had recently and if they can share what is the resolution?

    I installed the latest plugin (2.2.1-h-1) in Hudson server (Hudson ver. 3.0.0).
    Security configuration is set to Active Directory with a valid bind credential. The same AD bind credential can access to a repository via console or command line: only after the user supplied the credentials. However when another AD user logged in and run the build job with the GIT repository as SCM it yields this error:

    --------
    ERROR: Problem fetching from origin / origin - could be unavailable. Continuing anyway
    ERROR: (Underlying report) : Error performing command: /usr/bin/git fetch -t http://mydomain.com/git/projects/proj1.git +refs/heads/:refs/remotes/origin/
    Command "/usr/bin/git fetch -t http://mydomain.com/git/projects/proj1.git +refs/heads/:refs/remotes/origin/" returned status code 128: error: The requested URL returned error: 401 Authorization Required while accessing http://mydomain.com/git/projects/proj1.git/info/refs

    fatal: HTTP request failed
    --------

    Seems the plugin could not pass AD-authenticated credentials.

    I tried configuring 'Config user.name Value' and 'Config user.email Value' in the project/job specific Advanced configuration of Git (SCM section) using the AD bind account I use in Security setting and yielding the same error.

    Appreciate if someone can help.

    GIT version in the build server: 1.7.1
    GIT version in the SCM server: 1.7.11.3

    Thanks.