This plugin allows use of Git as a build SCM, including repository browsers for several providers. A recent Git runtime is required (1.7.9 minimum, 1.8.x recommended). Interaction with the Git runtime is performed by the use of the Git Client Plugin, which is only tested on official git client. Use exotic installations at your own risk.

Configuration

Global Settings

In the Configure System page, the Git Plugin provides the following options

Global Configuser.nameValue: if provided git config user.name <value> is called before builds. This can be overridden by individual projects.

Global Configuser.emailValue: if provided git config user.email <value> is called before builds. This can be overridden by individual projects.

Create new accounts base on author/committer's email: if checked, upon parsing of git change logs, new user accounts are created on demand for the identified committers / authors in the internal Jenkins database. The e-mail address is used as the id of the account.

Pipeline Scripts

Please note that these config variables are not passed through to Pipeline jobs
JENKINS-43563
-
Getting issue details...STATUS
So this configuration will need to be added in the job if you wish to make git commits

Project Configuration

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

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

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

The following are examples of valid git URLs.

ssh://git@github.com/org-name/project-name.git

git@github.com:org-name/project.git (short notation for ssh protocol)

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

If the repository is a super-project, the location from which to clone submodules is dependent on whether the repository is bare or non-bare (i.e. has a working directory).

If the super-project is bare, the location of the submodules will be taken from .gitmodules.

If the super-project is not bare, it is assumed that the repository has each of its submodules cloned and checked out appropriately. Thus, the submodules will be taken directly from a path like ${SUPER_PROJECT_URL}/${SUBMODULE}, rather than relying on information from .gitmodules.

For a local URL/path to a super-project, git rev-parse --is-bare-repository is used to detect whether the super-project is bare or not.

For a remote URL to a super-project, the ending of the URL determines whether a bare or non-bare repository is assumed:

If the remote URL ends with /.git, a non-bare repository is assumed.

If the remote URL does NOT end with /.git, a bare repository is assumed.

Credentials: Credentials to use to connect to the repository (unless anonymous access is allowed), using the Jenkins Credentials Management functionality. The type of credentials used depends on the underlying protocol. For SSH connections only private key authentication is supported.

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

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

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

Bugs

Check the open issues carefully to see if the issue has already been reported

Create an issue if needed, and make sure to choose the git-plugin sub-component. Make sure to mention the plugin version number in the issue description.

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 the user Jenkins is running as. Such user is probably tomcat6, but you can easily find out by creating an empty job and entering "whoami" in an "execute shell" build step, then running the job and looking at the console output for the username. Once you have the name, on a Linux/Unix system switch to that user by using either of the following, which works even if the user doesn't have shell access.

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

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

Git for Windows executable path

The "Path to executable" for "Git for Windows" is C:\Program Files\Git\cmd\git.exe

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 and in Windows Server 2012 R2 is C:\Windows\system32\config\systemprofile

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.

Git for Windows Installation and Windows Certificate Stores

A simpler approach with handling certificates in Windows is to configure Git to "Use the native Windows Secure Channel library" during its installation. This configures Git to use the Windows certificate stores to find certificates it needs to connect to remote repositories. Most typical Windows users use the Windows certificate stores to store web server certificates and personal certificates (e.g. pkcs #12) so using this setting makes sense. If you find that you are unable to clone a repository that uses https or requires a personal certificate for authentication, reinstall the Git client with this setting. One such error that relates to an authentication failure when connecting to a remote git repository is the following:

ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.

Visual Studio 2017 local source repositories

The Git repository URL for local Visual Studio 2017 repositories is "file:///c/users/<user>/source/repos/<solution/project>"

Example:

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.

Are configured to build the optionally specified branches or commit ID

For jobs that meet these conditions, polling will be immediately triggered. If polling finds a change worthy of a build, a build will in turn be triggered.

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.

Enabling JGit

The git client plugin provides multiple git implementations. The default git implementation relies on command line git. Command line git must be installed on each agent.

Administrators can enable a pure java implementation of the git protocol from the "Git" button in "Manage Jenkins" > "Global Tool Configuration". Implementations are added with the "Add" button. Once JGit (or JGit apache) has been added, jobs will include a picklist "Git executable" in the git configuration section of the job.

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.

Environment variables

The git plugin sets several environment variables you can use in your scripts:

GIT_COMMIT - SHA of the current

GIT_BRANCH - Name of the remote repository (defaults to origin), followed by name of the branch currently being used, e.g. "origin/master" or "origin/foo"

GIT_LOCAL_BRANCH - Name of the branch on Jenkins. When the "checkout to specific local branch" behavior is configured, the variable is published. If the behavior is configured as null or **, the property will contain the resulting local branch name sans the remote name.

GIT_PREVIOUS_COMMIT - SHA of the previous built commit from the same branch (not set on first build on a branch)

GIT_PREVIOUS_SUCCESSFUL_COMMIT - SHA of the previous successfully built commit from the same branch (not set on first build on a branch)

GIT_URL - Repository remote URL

GIT_URL_N - Repository remote URLs when there are more than 1 remotes, e.g. GIT_URL_1, GIT_URL_2

GIT_AUTHOR_NAME and GIT_COMMITTER_NAME - The name entered if the "Custom user name/e-mail address" behaviour is enabled; falls back to the value entered in the Jenkins system config under "Global Config user.name Value" (if any)

GIT_AUTHOR_EMAIL and GIT_COMMITTER_EMAIL - The email entered if the "Custom user name/e-mail address" behaviour is enabled; falls back to the value entered in the Jenkins system config under "Global Config user.email Value" (if any)

Version 3.5.0 (July 28, 2017)

(Internal, not user visible) Provide an extension for downstream SCMSource plugins to use for PR merging that disables shallow clones when doing a PR-merge (JENKINS-45771)

Version 3.4.1 (July 18, 2017)

Fix credentials field being incorrectly marked as transient (JENKINS-45598)

Version 3.4.0 (July 17, 2017)

Refactor the Git Branch Source UI / UX to simplify configuration and enable configuration options to be shared with dependent plugins such as GitHub Branch Source and Bitbucket Branch Source (JENKINS-43507). Please consult the linked ticket for full details. The high-level changes are:

There were a number of behaviours that are valid when used from a standalone job but are not valid in the context of a branch source and a multibranch project. These behaviours did not (and could not) work when configured against a branch source. These behaviours have been removed as configuration options for a Git Branch Source.

In the context of a multibranch project, the checkout to local branch behaviour will now just check out to the branch name that matches the name of the branch. The ability to specify a fixed custom branch name does not make sense in the context of a multibranch project.

Because each branch job in a multibranch project will only ever build the one specific branch, the default behaviour for a Git Branch Source is now to use a minimal refspec corresponding to just the required branch. Tags will not be checked out by default. If you have a multibranch project that requires the full set of ref-specs (for example, you might have a pipeline that will use some analysis tool on the diff with some other branch) you can restore the previous behaviour by adding the "Advanced Clone Behaviours". Note: In some cases you may also need to add the "Specify ref specs" behaviour.

Version 3.0.0-beta2 (July 6, 2016)

Add many more git options to multi-branch project plugin and literate plugin (plugins which use GitSCMSource)

Improved help for regex branch specifiers and branch name matching

Improve github browser guesser for more forms of GitHub URL

Use Jenkins common controls for numeric entry in fields which are limited to numbers (like shallow clone depth). Blocks the user from inserting alphabetic characters into a field which should take numbers

Honor refspec on initial fetch (JENKINS-31393) (note, some users may depend on the old, poor behavior that the plugin fetched all refspecs even though the user had specified a narrower refspec. Those users can delete their refspec or modify it to be as wide as they need)

Disallow deletion of the last repository entry in git configuration (JENKINS-33956)

Version 2.5.2 (July 4, 2016)

Version 2.5.1 (July 2, 2016)

Add many more git options to multi-branch project plugin and literate plugin (plugins which use GitSCMSource)

Improved help for regex branch specifiers and branch name matching

Improve github browser guesser for more forms of GitHub URL

Use Jenkins common controls for numeric entry in fields which are limited to numbers (like shallow clone depth). Blocks the user from inserting alphabetic characters into a field which should take numbers

Honor refspec on initial fetch (JENKINS-31393) (note, some users may depend on the old, poor behavior that the plugin fetched all refspecs even though the user had specified a narrower refspec. Those users can delete their refspec or modify it to be as wide as they need)

Disallow deletion of the last repository entry in git configuration (JENKINS-33956)

Version 2.5.0 (June 19, 2016) - Submodule authentication has moved into git 3.0.0-beta

Basic support for excluded regions and excluded users in polling added (JENKINS-4556)

Support for optionally checking out to a local branch, rather than detached HEAD (JENKINS-6856)

Revamped GitPublisher to allow for pushing tags to remotes and pushing to remote branches, as well as existing push of merge results. (JENKINS-5371)

Version 0.9.2 (June 22, 2010)

Fixed major bug in BuildChooser default selection and serialization (JENKINS-6827)

Version 0.9.1 (June 22, 2010)

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

Version 0.9 (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 use SHA1-ID, like build origin/bdbbfc3f0e9c57fbeff89de2ad7ca308a168575e and it would work. This is necessary for reproducibility.

Unknown User (evoturvey@gmail.com)

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:

Unknown User (gtsimpson24)

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.

Unknown User (bradleyrobertson@gmail.com)

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

Unknown User (bradleyrobertson@gmail.com)

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.

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)

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)

Unknown User (mmoo9154)

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.

Unknown User (david.antliff)

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

Unknown User (nick.porter@tradar.com)

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.

Unknown User (daleh)

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:

Unknown User (daleh)

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.

Unknown User (adam.szecowka)

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 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!

Unknown User (nvie)

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

Unknown User (mhasnaine@gmail.com)

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.

Unknown User (david.antliff)

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

Unknown User (david.antliff)

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?

Unknown User (david.antliff)

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.

Unknown User (david.antliff)

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.

Unknown User (david.antliff)

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

Unknown User (david.antliff)

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!

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.

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.

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?

Unknown User (david.antliff)

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

Unknown User (ppgengler)

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

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 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?

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

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

For Jenkins matrix builds that use the git plugin, I have this case where the flyweight task will run on the master node while the actual non-flyweight tasks are all done on the slave nodes. On the master node the reference repo is located on D:/ref.git while on the slaves it's C:/ref.git. This is a restricted parameter unfortunately. Is it possible to build a search path, such that if the reference repo isn't found in D:/ref.git, the next place to look is C:/ref.git? I've tried to make two advanced clone behaviors with those paths specified, and it didn't work as expected. I've also tried putting my ref.git in the Jenkins home directory hoping to use a relative path like $

Unknown macro: {WORKSPACE}

/../../ref.git, but $

for the actual jobs done on the slave nodes expands to a much longer path (perhaps a few levels down due to the axes) than the flyweight job done on the master. So using relative paths will not work. Any suggestions?

What I obviously meant, without all the annoying unknown macro stuff and failing the captcha a bunch of times:

"I've also tried putting my ref.git in the Jenkins home directory hoping to use a relative path like WORKSPACE/../../ref.git, but for the actual jobs done on the slave nodes expands to a much longer path (perhaps a few levels down due to the axes) than the flyweight job done on the master."

Just wanted to note that one way to resolve this is to assign the flyweight task to a slave node. That worked for me. However, I still think that searching for a reference repo should be a list of search paths.

I am attempting to configure a Jenkins build and set the source code management as a git repository. Whenever I try to do that. I get the error, "Failed to connect to repository : Command "git -c core.askpass=true ls-remote -h"

Starting with version 2.4.3, a new environment variable is published:
GIT_LOCAL_BRANCH: will be set to the local branch name derived from GIT_BRANCH when the check out to specific local branch option is set to null or "**".

The git plugin in hudson can config one git repository url and its localdirectorys, then another git repository url and its local directorys, but just one local dir in jenkins, so when it will support in jenkins?

The git plugin in hudson can config one git repository url and its localdirectorys, then another git repository url and its local directorys, but just one local dir in jenkins, so when it will support in jenkins?

2. I want to checkout content of repos/dir01 to subdir. Added "Checkout to subdirectory": subdir, and Sparce checkout paths": dir01. But plugin clones content of repos/dir01 to subdir/dir01. Is there any way to clone content direct to subdir?

I am trying to use this plugin in a freestyle Jenkins build, under Source Code Management. The git repository does clone, however I am trying to clone only master and this plugin always clones a specific revision of master, not the branch 'master' itself. This results in the repository being left in a detached head state and therefore I cannot commit any files from the working directory back to the repository. This is a huge problem for me, can someone explain why this plugin does not clone the named branch I specify in the settings? This plugin should be doing a normal clone operation, especially when a specific branch is named.

The Git plugin does a checkout to a detached head by default. This was introduced as a change quite a while back.

Current version of the Git plugin allows you to force checkout to a local branch name that matches the remote branch name. Select the "checkout to specific local branch" option and set the value to "**". This tells the Git plugin to do a checkout to a local branch with the same name as the remote sans the remote name (origin in this case). In your example, the local branch name would be 'master'.

That still doesn't seem to work properly. I am still seeing Jenkins checkout a revision of master, which is not at all what I need. How can I configure the plugin to clone/checkout exactly as a manually run "git clone" would do it? I need to be able to commit and push a modified file from this cloned repository, and this default behavior completely prevents that. Thanks for the help and guidance, btw.

The plugin is checking out exactly the commit you need, but it is not creating a branch at that point (since it does not need a branch to run a build).

You need a local branch. You can configure the plugin to create a local branch with the added behavior "Create local branch". Assign the value "**" to that branch name and it will use the remote branch name for the local branch name.

I am running Jenkins 1.635. According to this plugin page I only need Jenkins 1.625.3

However, when I go to the manage plugins page to upgrade the plugin it shows as requiring Jenkins 1.642.3:

This plugin allows use of Git as a build SCM, including repository browsers for several providers. A recent Git runtime is required (1.7.9 minimum, 1.8.x recommended). Interaction with the Git runtime is performed by the use of the [JENKINS:Git Client Plugin], which is only tested on official git client. Use exotic installations at your own risk.Warning: This plugin requires dependent plugins that are built for Jenkins 1.642.3 or newer. The dependent plugins may or may not work in your Jenkins and consequently this plugin may or may not work in your Jenkins.
Which one is it?

Jenkins runtime is the more accurate of the two. The git plugin declares its own specific version number dependencies (1.625.3), but apparently the version you're trying to download depends on a plugin which requires at least 1.642.3. That shows that I made a mistake when evaluating dependencies, or I chose to update a dependency for its features without correcting the base Jenkins version requirement for the git plugin.

If you're running that old a version of Jenkins, you should probably also remain on the exact versions of plugins that you're running on that Jenkins server. Jenkins 1.635 was released roughly 18 months ago. It was a weekly release, not a long term support release. It is no longer maintained. Even the long term support releases are typically only actively maintained for 3-6 months.

If you choose to upgrade plugins, you should probably also choose to upgrade Jenkins. If you choose to upgrade Jenkins, you should probably upgrade Jenkins to a long term support release so that you're using a version that spent some additional time in evaluation before it was released.

You say that is is "absent in this version". If by "this version" you mean a version of the git plugin that is less than 3.0, then that option is missing because it was not implemented until git plugin 3.0. If by "this version" you mean a version of the git plugin 3.0 or later, then please submit a bug report with detailed instructions to duplicate the problem.

Running Jenkins 2.46.3 with GitPlugin 2.5.3.In "Branches to build" we usually have ":origin/master", but sometimes we'd like to build specific branch. The issue that after we modified "Branches to build" to some branch and back to master, Jenkins is still checkout this branch, not master.Even removing the whole workspace doesn't help.How to force GitPlugin to checkout master?

Thanks, we'll submit a bug.This seems similar to
JENKINS-10408
-
Getting issue details...STATUS
, but it marked as fixed 5 years ago.BTW, I'm really curious to know where Jenkins/Gitplugin remember this branch details if I wiped the whole workspace.

No, the current branch definition is included in the job definition, independent of the workspace. It should not remember a previous branch definition in the workspace unless the new branch definition does not match any known branches.

I'm not aware of any location in the git plugin (other than the workspace) where it retains previous branch details. It retains details of previous SHA1 hashes of commits, and may maintain (in the BuildData) the branch names related to those SHA1 hashes.

Recently, multibranch pipeline (2.15, Jun 01 2017) allowed us to define Jenkinsfile Script Path in a sub-directory, which is very useful with multiple projects within a mono repository.The Git Plugin doesn't permit us to trigger a build with a path restriction on the same repository sub-directory, which result in an automatic triggering of every multibranch pipeline job for each push on the repository.

Can we expect a "path restriction" behaviour working with multibranch pipeline in a feature release ?

I do not expect to have a path restriction behavior in a future release of pipeline. Stephen Connolly has suggested a technique that might be used to implement author restrictions in pipeline, but path restrictions do not seem general case enough to apply to all pipeline use cases. JIRA bug report JENKINS-36195 is being used to track that progress.

I have a question about the recent changes affecting tag usage (apologies if this is the incorrect location)

Previously, with the 3.4.1 version of the plug in, we had a multi-branch pipeline set up that allowed us to respond to a new tag trigger from Github and produce a new 'branch' and build for that tag. This fits nicely in with our release process where we were tagging, building, and pushing an artefact.

After upgrading the plugin to 3.5.0, this is no longer possible due to changes in the branch discovery (as far as I can see). It seems there is a similar issue with the triggering. The changes imply that the kind of process I have wasn't ever intended to be supported. Is there an expected alternative flow that will give a similar result to the above (outside of just moving to Gitflow) or is that usage pattern outside the scope of the plugin? Is limited tag discovery something that is likely to return?

Mark Turner so the way you were using the plugin previously to discover tags was actually never intended to be the way tags should be discovered.

Tags discovered the way you had previously used would show up as an SCMHead that does not implement TagSCMHead and consequently the build behaviour would not be correct (you just were likely unaware of the issues or thought "that's just the way things are")

I believe that the typical Jenkins character set encoding is UTF-8, and the typical Japanese character set encoding on Windows was (at one time) SJIS. You may be encountering a bug in the git plugin or the git client plugin that it is mandating UTF-8 as the character set when it should be using the character set running on the operating system.

Sorry about answering to such old posts, but I believe my input may help other looking for hints here.

Jeff Gu, the workaround for your case would be to map your repository to a drive letter in the pre-SCM build step with Execute Windows batch file step and delete the mapping after the job is done.

Also you should avoid serving Subversion repositories, specifically those shared among many, from windows network share at all cost. See why. If you don't want to setup the server yourself by hand then try free CollabNet's Subversion Edge.

Oh, you're on git! Still I don't think it's safe to serve it from CIFS share. Some of the points from linked article may apply.

I'm trying to build Plugin version 3.6.3 on my computer. I cloned it from github and didn't modify anything. I got Java version 1.8.0_141-b15 and maven version 3.5.0 installed. I use "mvn clean install". I get the following error: Any Idea why this is happening?

I have a jenkins job for a maven multi module project with this structure:

Module A

Module B

desktop_App

common

...

I want to trigger the job that deploy the desktop_app only when changes are pushed to certain path, not the whole project. With git plugin it's supossed to do that but I put relative path on the white list field but scm ignore all commits

I'm having an issue when using the git plugin within a pipeline job. It used to work fine until I changed the value "Repository URL" in Job configuration page at Pipeline→Pipeline Script From SCM → Repositories → "Repository URL". Apparently the plugin is still trying to access the old repository according to the scm query protocol!!!

You can easily reproduce this error by creating a new Pipeline Job, choosing option "Pipeline Sript From SCM", choose git and enter a Repository URL (with has a Jenkinsfile). Now let one run be triggered by an SCM query and wait until the job is finished. Now go back to the configuration page of the job, change the Repository URL and let a new job be triggered. Now you can see in the protocol that git is still polling from the old repository. Looks like a bug to me.

I'm using Jenkins 2.73.3, git plugin version 3.6.4,pipeline version 2.5

No, the job XML cannot be updated to change the value if the "Git executable" pick list is missing.

if you don't have an option "Git executable" in your job definition, the Jenkins administrator has configured only one git implementation in the "Manage Jenkins" → "Global Tool Configuration" → "Git" section. The administrator will need to add a git installation (preferably called "Default") with the value "git". The "Git executable" list will then show in the pick list and you can select the new git installation from that pick list.

I am trying to access the git commit message from a batch command. I've scoured google and I can't find any clear description of how to do this. Is there a way to do it with this plugin?

Ultimately what I want to do is have Jenkins pick up on keywords inserted into our commit message (like #checkversion for example) and take action based on them. I can easily have the batch script handle all this if I could just get access to the commit message.

The SHA1 hash of the most recent commit is available as environment variable GIT_COMMIT (Freestyle) and as part of the map returned by checkout (Scripted Pipeline) and the environment (Declarative Pipeline).

I've tried about a hundred other variations of the same thing including double escaping the variables etc etc. I'm guessing that I'm missing something that noone thought I needed to be told because I'm such a newb .

Frankly I'm not sure if this is a Git plugin (3.8.0) or a Git Client plugin (2.7.1) issue.

We have been using Jenkins with a z/OS agent to run builds on z/OS using Git as our SCM. We had no problems with version 3.0.0/2.1.0 of the Git/GIt Client plugin but we tried to upgrade to the latest and Git rev-parse fails like below on a clean workspace.

We have tracked down the problem to the code page of the SSH key file in <workspace>/<project>@tmp. In the older versions, the SSH key file appears to be in EBCDIC and works but with the latest versions, the file is in utf-8. We verified this problem by running a script in place of the git command that does a code page conversion on the key file before issuing the git command.

I'm not sure where the delineation between Git plugin and Git client plugin falls or who writes out the key file.

Can you comment on where this problem may have originated and whether is was intended or a side effect of another change?

The git client plugin is the interface between command line git (and JGit) and the rest of the system. I believe that the previous implementation used the default character set. More recent versions specify the character.

There is not a way to control the character set. I don't intend to add an option to control the character set. I'm glad that the agent works on zOS for you, but I have no facility to test or verify on zOS.

Is it by design that the GitHub service/integration for this plugin pushes a notification to Jenkins when a branch gets deleted? Our feature branches are built successfully, but when we delete them (after merging a pull request into the main development branch), Jenkins gets a push notification that specifies that branch, tries to build it again and fails because the branch doesn't exist anymore. The error I see in the build output is simply:

FATAL: Could not checkout [my-branch-name] with start point [some SHA1]

Use a more precise form to specify the branch name. Refer to the online help for the 'branch to build' field. The branch name that you used is ambiguous and will match any branch name that ends with the word 'master'.

<remoteRepoName>/<branchName>Tracks/checks out the specified branch. If ambiguous the first result is taken, which is not necessarily the expected one.Better use refs/heads/<branchName>.E.g. origin/master

remotes/<remoteRepoName>/<branchName>Tracks/checks out the specified branch.E.g. remotes/origin/master

refs/remotes/<remoteRepoName>/<branchName>Tracks/checks out the specified branch.E.g. refs/remotes/origin/master

<tagName>This does not work since the tag will not be recognized as tag.Use refs/tags/<tagName> instead.E.g. git-2.3.0

refs/tags/<tagName>Tracks/checks out the specified tag.E.g. refs/tags/git-2.3.0

${ENV_VARIABLE}It is also possible to use environment variables. In this case the variables are evaluated and the result is used as described above.E.g. ${TREEISH}, refs/tags/${TAGNAME},...

<Wildcards>The syntax is of the form: REPOSITORYNAME/BRANCH. In addition, BRANCH is recognized as a shorthand of */BRANCH, '*' is recognized as a wildcard, and '**' is recognized as wildcard that includes the separator '/'. Therefore, origin/branches* would match origin/branches-foo but not origin/branches/foo, while origin/branches** would match both origin/branches-foo and origin/branches/foo.

:<regular expression>The syntax is of the form: :regexp. Regular expression syntax in branches to build will only build those branches whose names match the regular expression.Examples:

:^(?!(origin/prefix)).*

matches: origin or origin/master or origin/feature

does not match: origin/prefix or origin/prefix_123 or origin/prefix-abc

:origin/release-\d{8}

matches: origin/release-20150101

does not match: origin/release-2015010 or origin/release-201501011 or origin/release-20150101-something

:^(?!origin/master$|origin/develop$).*

matches: origin/branch1 or origin/branch-2 or origin/master123 or origin/develop-123

Hello, we are trying to identify what is the best way to have one single job with 4 different repositories on it and make sure we decide where do we checkout each of the repositories. We have the option to have and then we could use the feature Check out to a sub-directory. Is it possible to specify for each of the repositories the checkout sub-directory? This is because the check-out sub directory is not directly under each repository but in a different session so I don't see how do they link.

A Freestyle job using the git plugin can't operate with more than one independent repository. The option to use multiple repositories was created with the assumption that all those repositories represent the same conceptual repository, stored in different locations.

Using multiple repositories from a single job requires a Multi-branch Pipeline job (strongly preferred), a Pipeline job (preferred), or using the multiple SCM's plugin (not recommended) in a Freestyle job.

It looks like the variables set by the Git plugin are not available when using a pipeline.

As per the documentation:

GIT_LOCAL_BRANCH - Name of the branch on Jenkins. When the "checkout to specific local branch" behavior is configured, the variable is published. If the behavior is configured as null or **, the property will contain the resulting local branch name sans the remote name.

I have set checkout to specific local branch to **

In the pipeline, I print the env variables using:

echo bat(script: 'env|sort', returnStdout: true)

The result shows no env variable named GIT_LOCAL_BRANCH or any other variable mentioned above at Environment variables.

Could it be that the pipeline is run in another process than the one Jenkins uses to set the env variables?

The answer from Robert Sandell is correct. The checkout scm step returns a map of variables. Environment variables are not really workable for a Pipeline job, since the Pipeline job may perform multiple checkouts and environment variable values would be overwritten.

Looking at the referenced above video, I am trying to setup mail notifications in a declarative pipeline Jenkinsfile.I am using the git step to clone a repo, and after the build steps, a post action, I have a mail notification which contains :

The git step is a simplified form of the checkout step. It does not include all the capabilities of the checkout step. Use the checkout step instead of the git step for those items which the git step does not support (like timeout and reference repositories and narrow refspecs).

The checkout step also allows the use of a reference repository and a narrow refspec. A reference repository can dramatically reduce the amount of data transferred from the remote git repository to the workspace. A narrow refspec can further reduce the data transfer from a remote git repository to the workspace. Refer to "Git in the Large" from Jenkins World 2017 and "Jenkins hints for large git repositories" from Jenkins World 2016 for more details on those two options and why they help.

The information regarding JGit seems a little dated. "Once the JGit functionality gaps are closed, we consider JGit will be the way to go. " Does this represent the current status? JGit has come a long way since this was included.

Also, I've discovered a requirement that should be documented. When using CLI git, it is possible to configure "none" for credentials when using ssh protocol. The CLI implementation appears to use ~/.ssh/id_rsa automatically even when "none" is configured for credentials. When using JGit, this is not the case, and it is necessary to configure credentials specifically. This should be mentioned in the JGit section.

Finally, it might be nice to include a reminder that if you want JGit to be the default implementation, that you need to move it to the top of the list of implementations in the Global Tools configuration section.

Once the JGit functionality gaps are closed, we consider JGit will be the way to go.

It should instead say:

Command line git is the reference implementation of all functionality in the Jenkins git plugin. JGit provides an alternate implementation which can be used in many situations. Gaps in JGit functionality are generally flagged with warning messages in build logs or with build failures.

For specific details of the functionality which is available in command line git but not available in JGit, refer to the automated tests of the git plugin and the git client plugin.

I have a pipeline build that is configured to retrieve source from two Git repositories. The first repository is configured with the "name" blank which defaults to 'origin' . The second repository is configured with the remote name of 'app'.

From this, it appears that the notifyCommit found the job, but after this, nothing happens. The job is not triggered and the polling log does not show that the repository was examined. It looks like the only repository that is checked during poling is the one named origin.

Should I be able to configure a pipeline job with multiple git repositories, and have the job started by a change to either of the repos?

I've not tested that configuration, so I don't know if it works. Pipeline shared library changes (which are from a second repository) triggered builds the last time I modified them. I think it is reasonable that multiple checkout steps in a Pipeline would listen for changes on each repository referenced in the checkout.

If anyone else had trouble getting it to display the SCM names, branches or URLs when you have more than one repository: you want the jenkins git plugin "Additional Behaviours" option "Unique SCM Name", or in Jenkins Job Builder (JJB) you want the "scm-name" property.

I expect it supports ${ENV_VARS} for the branch etc, though I haven't tested that yet. For me a static string was enough.

Without that, jobs that use the Jenkins Pipeline Plugin quickly become impossible to clearly interpret.

Maybe a low level question but does this plugin come into play when using GitHub Branch Source Plugin (2.4.1)We currently have this plugin installed Git Plugin (3.9.1)I wanted to confirm if when using the Github Branch Source Plugin to scan an entire organization (it creates a job for each repository with a jenkinsfile script in it) we have access to the environment variables listed above in a job (jenkinfile)

Thanks in advance for the answer.From what i've been able to see this is a great community, Congrats and thanks for the hard work and support

When Jenkins processing PR, I need to fetch refs/remotes/origin/$CHANGE_TARGET during checkout (for code coverage). Is it doable via Job Configuration or I have to do it into my Jenkinsfile? I don't like the 2nd option because it means that my job will run checkout twoce.