This plugin allows use of Git as a build SCM. A recent Git runtime is required (1.7.9 minimum, 1.8.x recommended). Plugin is only tested on official git client. Use exotic installations at your own risks.

Gotchas

If you are seeing output indicating Git could not clone, something like the output below, go to to the Jenkins 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 Jenkins is running as. To do this on a Linux/Unix system switch to that user which is probably tomcat6. Do this by using either of the following, which work even if the user is not supposed to have shell access.

$ su - -s /bin/bash tomcat6
$ sudo su - -s /bin/bash tomcat6

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

Jenkins, GIT plugin and Windows

Installing the plugin itself works like a charm but configuring the system to work properly under Windows can be a be tricky. Let´s see the problems you may run into.

Configuring Jenkins to use OpenSSH bundled with msysgit Windows installer

By default, the Jenkins Windows installer sets up Jenkins to run as a service on Windows, which runs as the “Local System account”, NOT your user account. Since the “Local System account” does not have SSH keys or known_hosts set up, “git clone” will hang during the build. It's possible to keep Jenkins running as the “Local System account” and clone repositories via SSH by making sure that the “Local System account” is set up with a properly configured .ssh directory (i.e. id_rsa, id_rsa.pub, AND known_hosts). On my Windows 7 x64 box, this directory is C:\Windows\SysWOW64\config\systemprofile\.ssh

The first time you connect via SSH to a remote server, you would normally get prompted with the question "Are you sure you want to continue connecting (yes/no)?", which would populate the remote server info in your ~/.ssh/known_hosts. Even with proper SSH keys set up for the Jenkins user, if you don't have a properly configured ~/.ssh/known_hosts, the build will still hang.

A quick way to generate this known_hosts file is to copy your Jenkins build SSH keys into C:\Program Files (x86)\Git\.ssh (so that ssh.exe can find them), and run

c:\>"C:\Program Files (x86)\Git\bin\ssh.exe" -T git@your.git.server

This will populate C:\Program Files (x86)\Git\.ssh\known_hosts and then you can just copy C:\Program Files (x86)\Git\.ssh to C:\Windows\SysWOW64\config\systemprofile\.ssh (the “Local System account” home).

Adding the server to your trusted list

First of all, if your system/user never connected to the git server, you will have to add the server to your list of trusted servers.
If you get something like this:

The authenticity of host 'GIT SERVER (127.0.0.1)' can't be established.
RSA key fingerprint is 41:d2:d9:31:76:7d:bd:0d:5e:3f:19:db:5d:34:4d:9d.
Are you sure you want to continue connecting (yes/no)? yes

or

The server's host key is not cached in the registry...

Find plink.exe on your system and run:

plink.exe yourgitserver.com

Answer Yes when prompt. You ignore the login part with CTRL+C.
Beware, this is user specific. SO if you run jenkins as user 'John', make sure you login as 'John' before running the previous command.

An alternative option is to add some entries in the registry to HKEY_USERS\.DEFAULT. You will typically run into this problem is you let Jenkins runn as "Local System" but try to add the key to your list while logged in with your user. The registry entries added for a specific user can be found here:

HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys

Setup your environment variables

General hint: Avoid spaces in environment paths

Mainly, you will need:

GIT_HOME => Folder where your git.exe is located

HOME => The parent folder of the folder containing your SSH Keys (e.g If your keys are in C:\SSHKeys, set HOME to C:)

PATH => Add the folder where your plink.exe is located

Once this is done, make sure you restart your consoles and the jenkins service.

SSH Keys

You will need to generate your SSH keys. The public key will have to be added/installed on the server. Systems like Gitorious, Gitosis or Github make it easy: you will have to simply copy/paste your key. If you need to setup the authentication with a 'simple' server, look for 'authorized_keys' in this document http://www.eng.cam.ac.uk/help/jpmg/ssh/authorized_keys_howto.html

Some windows fun

If you did everything, you should now have a ~/.ssh folder (c:\Users\Bob\.ssh for instance) and this folder contains your keys.
At that point, you may even be able to manually (from the console), clone your repository but Jenkins keeps failing with something like this:

code 128: Cloning into C:\Program Files\Jenkins\jobs\PG3\workspace...
fatal: The remote end hung up unexpectedly

If you run into this issue, you may need to copy the id_rsa* files from your ~./.ssh to another folder.
Find your git.exe and check if there is an .ssh folder there. If so, copy ~./ssh/id_rsa* to this folder and try again.

Push notification from repository

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 Jenkins when a new push occurs. To do this, add the following line in your hooks/post-receive file, where <URL of the Git repository> is the fully qualified URL you use when cloning this repository.

This will scan all the jobs that are configured to check out the specified URL and the optional branches. If they are also configured with polling, polling will be immediately triggered (and if that finds a change worthy of a build, a build will in turn be triggered). We require the polling configuration on the job so that we only trigger jobs that are supposed to be triggered from changes in the source tree.

This allows a script to remain the same when jobs come and go in Jenkins. 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 Jenkins, 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, the list of projects that were triggered is returned.

<commit ID is optional. If set, it will trigger a build immediately, without polling for changes. The advantage of this is that you then can have all pushes tested by jenkins, even when developers push at the same time.

Why Not JGit

As of 1.2.0, the Git plugin uses git-client-plugin for all Git low-level operation. git-client was extracted from git plugin 1.1.x code base, to ensure SoC and allow other plugins (gerrit, git-parameters...) to directly use and contribute to this one when needed.

The git-client plugin 1.0.4 used JGit by default, while still including the command line Git implementation as an alternate implementation. Initial deployments of the JGit based plugin exposed a number of gaps in the JGit implementation. Those gaps need to be resolved in the JGit implementation before it can be used as the default implementation. Beginning with git-client-plugin 1.0.5, the command line implementation is the default implementation.

The git-client-plugin provides both command line and JGit implementations for the GitClient interface. Using command line demonstrated (based on large git plugin issue list) to be fragile : running an external process any time some git repository interaction is required introduces file and process leaks, filesystem locks, etc. It's highly system dependent and require user to install and configure adequate tools on all build slaves. It's based on parsing command output, and as such can be broken by any git cli update - legacy code already check git-cli version to detect which option can be used. Once the JGit functionality gaps are closed, we consider JGit will be the way to go. If you want to experiment with the JGit implementation, either configure JGit as an available git installation from the "Manage Jenkins" page, or run Jenkins with -Dorg.jenkinsci.plugins.gitclient.Git.useCLI=false (same for slaves).

Fast Remote Polling

Fast Remote Polling is a feature that uses a speedy 'git ls-remote ...' command to perform the SCM polling action rather than having to a clone and fetch a local repository.

This feature is enabled by default as of versions 2.2+.

In the event that Fast Remote Polling is detected as being not possible (branches to build contains wildcards, etc), polling will fallback to requiring a workspace.

However, it is possible in some environments that Fast Remote Polling will not work due to the fact that it executes on the master and the master may not have a working Git installation.

A workaround for this is to add an additional behavior of Force polling using workspace to all jobs where you want to use SCM polling.

Advanced Features

Using Git, Jenkins and pre-build branch merging

Continuous Integration tools such as Jenkins 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 Jenkins, you can achieve the same 'stable branches' with minimal effort.

Set up your Jenkins project, and leave the 'branch' field in the Git SCM blank. This will cause Jenkins 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 Jenkins.

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.

Version 0.9.2 (released June 22, 2010)

Version 0.9.1 (released June 22, 2010)

Dramatic improvement in changelog generation, thanks to a switch to use "git whatchanged" (issue #6781)

Version 0.9 (released June 17, 2010)

Improved support for BuildChooser as an extension point - other plugins can now implement their own BuildChoosers and have them automatically show up as an option in Git configuration when installed.

Options added for wiping out the workspace before the build begins (this option may be removed), and for using commit authors as the Hudson changelog entry author, rather than the committers, the default behavior.

How do I build a specific revision? I used to be able to specify a build should ...

How do I build a specific revision? I used to be able to specify a build should use SHA1-ID, like build origin/bdbbfc3f0e9c57fbeff89de2ad7ca308a168575e and it would work. This is necessary for reproducibility.

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:

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:

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.

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/masterbranch to build: */masterbranch 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?

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.

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.

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)

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)

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.

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 :)

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.

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:

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.

I have the same situation as Adam. We need to be able to clone two separate repo...

I have the same situation as Adam. We need to be able to clone two separate repos side-by-side in the workspace - the same way we can do so with the Jenkins SVN plugin. This plugin appears to try cloning both repos into the same directory. Is there any way to do this??

The "Advanced" button at the bottom of the Git section in the build configuration reveals an option for "Local subdirectory for repo (optional)" but it's not specific to a defined repo. I'm not sure how this makes sense to have as a "global" option when you can specify multiple repos.

Anyone have any ideas?

UPDATE: This is being tracked in JENKINS-8082, which should be a feature request I'm guessing

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!

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).

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.

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):

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.

Errors

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?

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.

Again I ask politely yet earnestly for this bug to be addressed please.
My curr...

Again I ask politely yet earnestly for this bug to be addressed please.

My current workaround involves every build deleting all local tags and then re-fetching them from the server. This is becoming slower and slower as more tags appear in the repository. If I don't do this, the parent repository is completely overwhelmed with tags that have 'leaked' from the submodules into the parent repository. More recently I have been creating a new style of Jenkins jobs that are almost completely broken by this bug because they rely on specific tags to be present (or not present) at the start of the process.

Clearly this plugin should not be adding tags defined in submodules to the reference database of the parent repository!

Again, if there's anything I can do to help debug this, please let me know. I am happy to help if we can get this bug fixed.

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

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.

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

It looks the GIT plugin from Hudson is not able to find the ssh keys. When i tri...

It looks the GIT plugin from Hudson is not able to find the ssh keys. When i tried from GIT Bash i could see the commands are working fine but the same when executed via GIT Plugin in Hudson, i see the above discussed errors. Also, I tried looking at the environment variables from HUDSON, and i see the variable HOME pointing this directory. I see many suggestions on Linux but not anything on Windows. Could any one suggest me how to get it configured? My environment is on windows 7 and the hudson sits on Tomcat and the .ssh directory is in H. Thanks!

Hi,
Is there anyway to limit the size of the history in the changelog ? I have ...

Hi,

Is there anyway to limit the size of the history in the changelog ? I have just imported a large module into a git subtree with 1000s of changes (changelog.xml is 203MB) , this is causing Jenkins to run out of memory. If I manually delete the changelog.xml files and restart Jenkins this is fine but I think the problem can occur again if I create new slave nodes or import other repositories.

Hi,
Is there a way to tag certain builds from the Jenkins dashboard? I don't wa...

Hi,

Is there a way to tag certain builds from the Jenkins dashboard? I don't want every build to be automatically tagged, but for some builds it would be nice to push a button in Jenkins and lat it tag the buildnr to git.

Hi,
I have a project building from GIT tags. I couldn't see the list of changes...

Hi,

I have a project building from GIT tags. I couldn't see the list of changes between two tags. But I could see changes in other projects which build from GIT branches. Is the GIT tag the reason for this issue?

Perhaps I'm missing something, but why would the git plugin be attempting to del...

Perhaps I'm missing something, but why would the git plugin be attempting to delete a local tag that doesn't exist? I have git configured to build and perform a maven release on any change to master.
The repository definition has the "Skip Internal Tag" selected, which should not create a job tag, correct? However, after creating a maven release which successfully deploys, the job is failing on delete of the jenkins job tag.
Is this working as designed? Is there a workaround to skip the deletion of that tag??

Is the GIT_BRANCH macro supposed to include the repository/remote name? In other...

Is the GIT_BRANCH macro supposed to include the repository/remote name? In other words, should it look like "origin/master" or just "master"? The comment on issue #9510 seems to suggest that it should not include that part.

The reason I ask is that I am trying to chain some jobs together, so that an SCM change triggers a build, then the build job triggers a parameterized test job to run tests on the branch that changed. The build job is passing $GIT_BRANCH into the test job's "branch" parameter, and this parameter's value is used in the "Branches to build" field of the test job. But because the GIT_BRANCH includes the "origin" part, the test job is failing with the message "ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job."

Jenkins doesn't provide any easy way to manipulate the strings used in fields like that, so it seem like the GIT_BRANCH should either not include the remote name, or the plugin should be smart enough to strip it out if passed into the "Branches to build" field.

Is there a way to use a token / variable as the branch specifier? In other words...

Is there a way to use a token / variable as the branch specifier? In other words, if the title of my job is "dev_branch", can I set the branch specifier to be "${JOB_TITLE}" or something in order to checkout dev_branch? I'm interested in doing this so that I can easily clone existing jobs to build different branches in the same repository, and all I would need to change is the job title...

Then the problem goes away. I haven't been able to diagnose it fully because I haven't caught it fast enough. By the time I come across it, several more builds have gone through the workspace successfully.

Has anyone else had issues with "git clean" failing intermittently using this plugin?

I'm having an issue with some builds coming through with "origin/HEAD" in the GI...

I'm having an issue with some builds coming through with "origin/HEAD" in the GIT_BRANCH variable, when what has actually changed is the master branch. My intention is to build any branch that has changed, and use the GIT_BRANCH variable to determine which branch it is, so I know where to copy the build output and so forth. However, I do not want to ever see HEAD builds. Anything that's not an actual branch name is meaningless to me and my team. How can I prevent this? I've tried the new inverse strategy with "*/HEAD", but that did not work.

Hi,
I use various labels for branches in git (i.e. release/, hotfix/, feature/,...

Hi,

I use various labels for branches in git (i.e. release/, hotfix/, feature/, etc.) and I'd like to have a worker that builds a specific pattern of branch. For example on release/* I want to do different things for the build, and I don't want to build any feature/, etc. Is there some way to do this? I've tried (I think) release, release/* and release/** and none of those work.

Related side note, it'd be nice as part of this plugin to have it do a dry-run of the branch picking strategy so that you could set the Branch Specifier and then check what it returns; currently I have to change, request a build, see it fail, change again ...

I just want git to to check some branches for changes and work as trigger for a ...

I just want git to to check some branches for changes and work as trigger for a job. That means no cloning, tagging, whatsoever. Since I want to get some stuff from the git log (timestamp, revision, tag etc) and the plug in messes that up, up until now I have to remove the files first and then clone the repository again "myself". How can I archive that? I stumbled over "disabling of internal tagging (issue #5676), but that is not "enough".

I've got to say. The logging or diagnostic capabilities surrounding initial setup (such as the "git clone" that occurs on a job's first run) definitely need some work.

A windows user like myself has more hangups than others to get it up and running, all of which would be easier to identify with better logging. Here are some major common problems that prevent someone from picking up and using this plugin:

This plugin does not gracefully handle spaces in path names. It's probably not the only one.

Defaulting to "git.exe" rather than "git" produces the ambiguity on windows systems that actually use "git.cmd".

I was not allowed to use my actual ".ssh" directory which is on H: instead of C: . So now I have two copies!

The "trusted host" nonsense is a bear especially considering there are now two copies of all my .ssh settings floating about, one of which specifically catered to jenkins.

All of this is incredibly difficult to diagnose because "git clone" hangs and fails silently, and this should be rearchitected. There are many blog posts floating about the internet each seemingly individually solving these problems after a long day's work. The problems above could all be alleviated considerably if users are given more information to point them in the right direction.

Is there anything I can update in my builds so that I can delete all the grey/aborted builds that show up for all my topic branches? Right now, nobody can easily see status - each topic branch has 5 jobs, 2 of which are grey - making the sub-view grey. If I delete the aborted builds, the whole cycle starts again.

I was very keen on the option of "Merge Before Build." That makes a lot of sense...

I was very keen on the option of "Merge Before Build." That makes a lot of sense to allow feature branches to validate against a downstream branch like "master" (assuming a Gitflow-like workflow where master is what's on production). However, using Maven the version in POM files on master would be, by definition, always behind the feature branch version. Therefore, the "merge before build" would always fail. Am I missing something? For example:

master branch version is 1.0.0

feature branch version is 1.1.0-SNAPSHOT

Git merge would fail every time via this plugin because it would not know how to deal with those version numbers. Has anyone else hit this?

I need a little help. I have installed Git and I have installed Jenkins, and as ...

I need a little help. I have installed Git and I have installed Jenkins, and as far as I know, I have installed a version of the Git Client? But I am having difficulty getting it to go correctly.

I am installing on Linux Ubuntu 10.04 LTS. As far as I know have the Jenkins user home directory set correctly, SSH more or less configured. How do I tell a Jenkins Job that it's got Git? My only choices are CVS, None, and Subversion.

Is it possible to exclude certain directories/files from being removed when usin...

Is it possible to exclude certain directories/files from being removed when using the "Clean after checkout" option?
I use a private local Maven repository sitting in the workspace of a Gerrit verification job.
I would like to keep this local Maven repository for performance reasons, while using "Clean after checkout".
Sort of: "exclude=$WORKSPACE/.repository"

In addition to an exclude option for "Clean after checkout", I would like to have an include option, where I would then specify certain hierarchies within the private local repository to be cleaned, like "include=$WORKSPACE/.repository/org/myorg/".

If not, would it make sense to create a ticket to add this?
The git plugin could potentially consume all its known parameters (url, branches, sha1), and if there are any parameters left, pass them to the jobs configured with that git url. These jobs would be called with /buildWithParameters, and all the extra parameters would be passed to them.

It gives a solution for "automatically build the latest tag in a git repository", not limited to specific branch. It can be easily adopted to look for tags meeting some regular expression, unfortunately I don't have a reliable way to predict what future tags will look like.

Hi,
I have been trying to use the below environment variables in the jenkins jo...

Hi,

I have been trying to use the below environment variables in the jenkins job but unable to access them:

GIT_AUTHOR_EMAIL - Committer/Author Email

GIT_COMMITTER_EMAIL - Committer/Author Email

I tried executing 'printenv' in the shell script build step and could not see these two env variables listed. However I could see other env variables set like GIT_URL, GIT_COMMIT, GIT_BRANCH.. Can anybody please let me know if these two env variables are broken or if I am missing something here?

Good day. Please, help to find out, does Parameter still work for Git plugins in...

Good day. Please, help to find out, does Parameter still work for Git plugins in SCM.

I have parameterized build, set up a "String parameter", for example name is BRANCH with default value master. Ok.Next, i have schedule for checking changes in git. So, when SCM check repo it doesn't use default value for parameter BRANCH, it check repo as is. I saw in git poll:

> git.exe ls-remote -h git@gitlab:some_repo.git $BRANCH

Is here any chance to use default value for env. variable on SCM check?

Hi,
I have a repository with a submodule, both are managed by gerrit.
Builds f...

Hi,

I have a repository with a submodule, both are managed by gerrit.

Builds for this repo are triggered manually by the users.

I'm using REFSPEC for the supermodule and an optional SUB_REFSPEC for the submodule. This is required because some changes have cross-dependencies, so users should be able to build them together (e.g. REFSPEC=refs/changes/12/3012/3, SUB_REFSPEC=refs/changes/13/3013/5)

Fetch and Checkout are done using a script, but I would like to have a list of changes for both the supermodule and the submodule (based on a reference branch which is identical for both).

What are the dependencies for version 2.2.8 or 2.2.9 ?
I can see the dependenci...

What are the dependencies for version 2.2.8 or 2.2.9 ?

I can see the dependencies for version 2.3 listed as: Jenkins-core 1.568, credentials-plugin 1.18, etc. But that's only because it's the latest/greatest version and therefore makes the header section of the its wiki-page.

In general, is there a way to find the dependencies for (slightly) older Jenkins plugins versions?

I want to trigger build if someone commit in Bitbuket's specific branch. Current...

I want to trigger build if someone commit in Bitbuket's specific branch. Currently we can mention which branch to build but on setting remote triggers it trigger build on code commit in any branch not only in given branch. I set Jenkins hook as well as post receive hook which triggers build remotely but by giving branch name it give error that no git repo or branch is set.

I want to trigger build if someone commit in Bitbuket's specific branch. Current...

I want to trigger build if someone commit in Bitbuket's specific branch. Currently we can mention which branch to build but on setting remote triggers it trigger build on code commit in any branch not only in given branch. I set Jenkins hook as well as post receive hook which triggers build remotely but by giving branch name it give error that no git repo or branch is set.

I've seen cases where polling seemed to no longer detect changes, and didn't see...

I've seen cases where polling seemed to no longer detect changes, and didn't see any reason I could use to justify why it stopped. Unfortunately, I also was unable to find any repeatable sequence of steps which would let me recreate the problem.

If you switch to an earlier git plugin, does it again detect changes?

You also may want to use the mailing list rather than the wiki pages for questions. It was quite by accident that I saw your question on the wiki page. I think many more people read the mailing list than read the comments in wiki pages.

Thanks Mark. I'll definitely use the mailing list in the future. I downgraded th...

Thanks Mark. I'll definitely use the mailing list in the future. I downgraded the Git plugin to v2.3.4 and changes we're immediately detected again. Not sure what changed in v2.3.5, but my system (Mac running Mavericks) certainly didn't like it.