Plugin Information
Plugin ID |
git |
Changes |
|
|---|---|---|---|
Latest Release |
3.5.1 (archives) |
Source Code |
GitHub |
Usage |
|
Installations |
2016-Sep 94614 |
Older versions of this plugin may not be safe to use. Please review the following warnings before using an older version:
Configuration
Global Settings
In the Configure System page, the Git Plugin provides the following options
- Global Config
user.nameValue: if providedgit config user.name <value>is called before builds. This can be overridden by individual projects. - Global Config
user.emailValue: if providedgit 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.
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.gitgit@github.com:org-name/project.git(short notation for ssh protocol)ssh://user@other.host.com/~/repos/R.git(to access the {repos/R.gitrepository in the user's home directory)https://github.com/github/git.gitgit://github.com/org-name/project.git
- If the repository is a super-project, the location from which to clone submodules is dependent on whether the repository is bare or non-bare (i.e. has a working directory).
- If the super-project is bare, the location of the submodules will be taken from
.gitmodules. - If the super-project is not bare, it is assumed that the repository has each of its submodules cloned and checked out appropriately. Thus, the submodules will be taken directly from a path like
${SUPER_PROJECT_URL}/${SUBMODULE}, rather than relying on information from.gitmodules.
- If the super-project is bare, the location of the submodules will be taken from
- For a local URL/path to a super-project,
git rev-parse --is-bare-repositoryis 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.
- If the remote URL ends with
- The following are examples of valid git URLs.
- 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.
Note: Source code can be found at https://github.com/jenkinsci/git-plugin.
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.
$ cd /srv/jenkins/jobs/project/workspace $ git config user.email "some@email.com" $ git config user.name "jenkins"
Don't setup a credential helper, or if one is defined, delete that section from the
~/.gitconfigfile. It can cause weird authentication issues.
When you are done, log off as the Jenkins user
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 bit 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 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).
For a more detailed tutorial, see http://computercamp-cdwilson-us.tumblr.com/post/48589650930/jenkins-git-clone-via-ssh-on-windows-7-x64
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
You can read this: http://help.github.com/win-set-up-git/ to see how to generate the keys.
One solution to avoid entering your password (the one you defined in the ssh key in the process above) is to use Pageant.exe. Visit the link below for more details: http://www.ualberta.ca/CNS/RESEARCH/LinuxClusters/pka-putty.html
Note:* future *integration with ssh-credentials-plugin could help
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.
curl http://yourserver/git/notifyCommit?url=<URL of the Git repository>[&branches=branch1[,branch2]*][&sha1=<commit ID>]
This will scan all the jobs that:
- Have Build Triggers > Poll SCM enabled. No polling Schedule is required.
- Are configured to build the repository at the specified URL
- 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.
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.
Recursive submodules
The GIT plugin supports repositories with submodules which in turn have submodules themselves. This must be turned on though: in Job Configuration -> Section Source Code Management, Git -> Advanced Button (under Branches to build) -> Recursively update submodules.
Environment variables
The git plugin sets several environment variables you can use in your scripts:
GIT_COMMIT- SHA of the currentGIT_BRANCH- Name of the remote repository (defaults toorigin), 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 (the current SHA on first build in branch)GIT_PREVIOUS_SUCCESSFUL_COMMIT- SHA of the previous successfully built commit from the same branch.GIT_URL- Repository remote URLGIT_URL_N- Repository remote URLs when there are more than 1 remotes, e.g. GIT_URL_1, GIT_URL_2GIT_AUTHOR_NAMEandGIT_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_EMAILandGIT_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)
Change Log
Version 3.5.1 (Aug 5, 2017)
Extend API for Blue Ocean pipeline editing support in git
Extend API to allow PreBuildMerge trait through a new plugin
Don't ignore branches with '/' in GitSCMFileSystem (JENKINS-42817)
Show folder scoped credentials in modern SCM (JENKINS-44271)
Version 3.5.0 (July 28, 2017)
Upgrade to Git Client Plugin version 2.5.0
Switch GitSCMSource indexing based on ls-remote to correctly determine orphaned branches (
JENKINS-44751
-
Getting issue details...
STATUS
)
(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
-
Getting issue details...
STATUS
)
Version 3.4.1 (July 18, 2017)
Fix credentials field being incorrectly marked as transient (
JENKINS-45598
-
Getting issue details...
STATUS
)
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.3.2 (July 10, 2017)
Version 3.3.1 (Jun 23, 2017)
Print first line of commit message in console log (JENKINS-38241)
Allow scm steps to return revision (JENKINS-26100)
Don't require crumb for POST to /git/notifyCommit even when CSRF is enabled (JENKINS-34350)
Fix credentials tracking null pointer exception in pipeline library use (JENKINS-44640)
Fix credentials tracking null pointer exception in git parameters use (JENKINS-44087)
Version 3.3.0 (Apr 21, 2017)
Track credentials use so that credentials show the jobs which use them (JENKINS-38827)
Add a "Branches" list view column (JENKINS-37331)
Add some Italian localization
Fix null pointer exception when pipeline definition includes a branch with no repository (JENKINS-43630)
Version 3.2.0 (Mar 28, 2017)
Add reporting API for default remote branch (JENKINS-40834)
Remove extra git tag actions from build results sidebar (JENKINS-35475)
Version 3.1.0 (Mar 4, 2017)
Add command line git large file support (LFS) (JENKINS-30318, JENKINS-35687, JENKINS-38708, JENKINS-40174)
Allow custom remote and refspec for GitSCMSource (JENKINS-40908)
Add help for GitSCMSource (JENKINS-42204)
Add help for multiple refspecs (JENKINS-42050)
Log a warning if buildsByBranchName is too large (JENKINS-19022)
Avoid incorrect triggers when processing events (JENKINS-42236)
Version 3.0.5 (Feb 9, 2017)
Please read this Blog Post before upgrading
Upgrade SCM API dependency to 2.0.3
JENKINS-41812 Expose event origin to listeners
Version 2.6.5 (Feb 9, 2017)
Please read this Blog Post before upgrading
Upgrade SCM API dependency to 2.0.3
JENKINS-41812 Expose event origin to listeners
Version 3.0.4 (Feb 2, 2017)
Please read this Blog Post before upgrading
Upgrade to latest SCM API dependency
Version 2.6.4 (Feb 2, 2017)
Please read this Blog Post before upgrading
Upgrade to latest SCM API dependency
Remove beta dependency that was left by mistake in the 2.6.2 release (this is what 2.6.2 should have been)
Version 3.0.3 (Jan 16, 2017)
Please read this Blog Post before upgrading
Remove beta dependency that was left by mistake in the 3.0.2 release (this is what 3.0.2 should have been)
Version 2.6.3 (SKIPPED)
This version number has been skipped to keep alignment of the patch version with the 3.0.x line until the SCM API coordinated releases have been published to the update center
Version 3.0.2 (Jan 16, 2017)
Please read this Blog Post before upgrading
Fix potential NPE in matching credentials PR #467
JENKINS-39837 Add API to allow plugins to configure the SCM browser after instantiation
Updated Japanese translations
JENKINS-39355 Upgrade to SCM API 2.0.x APIs
Fix help text PR #451
Version 2.6.2 (Jan 16, 2017)
Please read this Blog Post before upgrading
JENKINS-39837 Allow the SCM browser to be configured after SCM instance created.
Fixed translations
Fixed copyright
Updated Japanese translation
JENKINS-39355 Upgrade to SCM API 2.0.x APIs
API to get author or committer email without having to call getAuthor()
Version 3.0.2-beta-1 (16 Dec 2016)
Update to SCM-API 2.0.1 APIs (JENKINS-39355)
Add implementation of SCMFileSystem (JENKINS-40382)
Fix help text for excluded regions regex (PR#451)
Version 2.6.2-beta-1 (16 Dec 2016)
Update to SCM-API 2.0.1 APIs (JENKINS-39355)
Add implementation of SCMFileSystem (JENKINS-40382)
Version 3.0.1 (18 Nov 2016)
Allow retrieval of a single revision (for improved pipeline support) (JENKINS-31155)
Avoid null pointer exception in prebuild use of build data (JENKINS-34369)
Allow git credentials references from global configuration screens (JENKINS-38048)
Use correct specific version in workflow pipeline on subsequent builds (e15a43)
Version 2.6.1 (9 Nov 2016)
Allow retrieval of a single revision (for improved pipeline support) (JENKINS-31155)
Avoid null pointer exception in prebuild use of build data (JENKINS-34369)
Allow git credentials references from global configuration screens (JENKINS-38048)
Use correct specific version in workflow pipeline on subsequent builds (e15a43)
Version 3.0.0 (10 Sep 2016)
Add submodule authentication using same credentials as parent repository (JENKINS-20941)
Require JDK 7 and Jenkins 1.625 as minimum Jenkins version
Version 2.6.0 (2 Sep 2016)
Add command line git support to multi-branch pipeline jobs (JENKINS-33983, JENKINS-35565 JENKINS-35567, JENKINS-36958, JENKINS-37297)
Remove deleted branches from multi-branch cache when using command line git (JENKINS-37727)
Create multi-branch cache parent directories if needed (JENKINS-37482)
Use credentials API 2.1 (JENKINS-35525)
Version 2.5.3 (30 Jul 2016)
Prepare to coexist with git client plugin 2.0 when it changes from JGit 3 to JGit 4 (commit)
Fix gogs repository browser configuration (JENKINS-37066)
Optionally "honor refspec on initial clone" rather than always honoring refspec on initial clone (JENKINS-36507)
Don't ignore the checkout timeout value (JENKINS-22547)
Version 3.0.0-beta2 (6 Jul 2016)
Fix compatibility break introduced by git plugin 2.5.1 release (JENKINS-36419)
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 (4 Jul 2016)
Fix compatibility break introduced by git plugin 2.5.1 release (JENKINS-36419)
Version 2.5.1 (2 Jul 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 (19 Jun 2016) - Submodule authentication has moved into git 3.0.0-beta
Reject parameters passed through unauthenticated notifyCommit calls (SECURITY-275)
Don't generate error when two repos defined and specific SHA1 is built (JENKINS-26268)
Fix stack trace generated when AssemblaWeb used as git hosting service
Fix array index violation when e-mail address is single character "@"
Add support for gogs self-hosted git service
Use environment from executing node rather than using environment from master
Move pipeline GitStep from pipeline plugin to git plugin (JENKINS-35247); note that if you have the Pipeline: SCM Step plugin installed, you must update it as well
Version 3.0.0-beta1 (15 Jun 2016)
Continuation of git plugin 2.5.0-beta series (2.5.0 release number used for SECURITY-275 fix)
Don't generate error when two repos defined and specific SHA1 is built (JENKINS-26268)
Fix stack trace generated when AssemblaWeb used as git hosting service
Fix array index violation when e-mail address is single character "@"
Add support for gogs self-hosted git service
Use environment from executing node rather than using environment from master
Move pipeline GitStep from pipeline plugin to git plugin (JENKINS-35247)
Version 2.5.0-beta5 (Apr 19, 2016)
Fix botched merge that was included in 2.5.0-beta4
Include latest changes from master branch (git plugin 2.4.4)
Version 2.4.4 (Mar 24, 2016)
Fix git plugin 2.4.3 data loss when saving job definition (JENKINS-33695 and JENKINS-33564)
Restore BuildData.equals lost in git plugin 2.4.2 revert mistake (JENKINS-29326)
Version 2.4.3 (Mar 19, 2016)
Optionally derive local branch name from remote branch name (JENKINS-33202)
Allow shallow clone depth to be specified (JENKINS-24728)
Allow publishing from shallow clone if git version supports it (JENKINS-31108)
Allow GitHub browser guesser to work even if multiple refspecs defined for same URL (JENKINS-33409)
Clarify Team Foundation Server browser name (remove 2013 specific string)
Reduce memory use in difference calculation (JENKINS-31326)
Resolve several findbugs warnings
Version 2.4.2 (Feb 1, 2016)
Show changelog even if prune stale branches is enabled (JENKINS-29482)
Set GIT_PREVIOUS_SUCCESSFUL_COMMIT even if prune stale branches is enabled (JENKINS-32218)
Version 2.4.1 (Dec 26, 2015)
Allow clone to optionally not fetch tags (JENKINS-14572)
Allow submodules to use a reference repo (JENKINS-18666)
Use OR instead of AND when combining multiple refspecs (JENKINS-29796)
Remove dead branches from BuildData (JENKINS-29482)
Fix Java 6 date parsing error (JENKINS-29857)
Set changeset time correctly (JENKINS-30073)
Include parent SHA1 in RhodeCode diff URL (JENKINS-17117)
Don't set GIT_COMMIT to an empty value (JENKINS-27180)
Fix AssemblaWeb diff link (JENKINS-29731)
Attempt fix for multi-scm sporadic failures (JENKINS-26587)
Version 2.5.0-beta3 (Nov 12, 2015)
Still more work on submodule authentication support by allowing submodules to use parent credentials (JENKINS-20941)
Version 2.5.0-beta2 (Nov 8, 2015)
More work on submodule authentication support by allowing submodules to use parent credentials (JENKINS-20941)
Version 2.5.0-beta1 (Nov 4, 2015)
Submodule authentication support by allowing submodules to use parent credentials (JENKINS-20941)
Version 2.4.0 (Jul 18, 2015)
Branch spec help text improved (JENKINS-27115)
Allow additional notifyCommit arguments (JENKINS-27902)
Parameterized branch name handling improvements (Pull requests 226, 308, 309, JENKINS-27327, JENKINS-27351, JENKINS-27352)
Display error message in log when fetch fails (regression fix) (JENKINS-26225, JENKINS-27567, JENKINS-27886, JENKINS-28134)
Fix IllegalStateException when using notifyCommit URL (JENKINS-26582)
Allow branch specification regex which does not include '*' (JENKINS-26842)
Detect changes correctly when polling (JENKINS-27093, JENKINS-27332, JENKINS-27769)
Fix GitHub Webhook handling (JENKINS-27282)
Fix polling with a parameterized branch name (JENKINS-27349)
Don't throw exception when changelog entry is missing parent (JENKINS-28260, JENKINS-28290, JENKINS-28291)
Don't throw exception when saving GitLab browser config (JENKINS-28792)
Rebuild happened on each poll, even with no changes (JENKINS-29066)
Remote class loading issue work-around (JENKINS-21520)
Version 2.3.5 (Feb 18, 2015)
Support Microsoft Team Foundation Server 2013 as a git repository browser
Support more merge modes (fast forward, no fast forward, fast forward only (JENKINS-12402)
Handle regular expression branch name correctly even if it does not contain asterisk (JENKINS-26842)
Log the error stack trace if fetch fails (temporary diagnostic aid)
Version 2.3.4 (Jan 8, 2015)
Fix jelly page escape bug (which was visible in the GitHub plugin)
Version 2.2.12 (Jan 8, 2015)
Fix jelly page escape bug (which was visible in the GitHub plugin)
Version 2.3.3 (Jan 6, 2015)
Use git client plugin 1.15.0
Escape HTML generated into jelly pages with escape="true"
Expand environment variables in GitPublisher again (JENKINS-24786)
Version 2.2.11 (Jan 6, 2015)
Update to JGit 3.6.1
Use git client plugin 1.15.0
Escape HTML generated into jelly pages with escape="true"
Fix multiple builds can be triggered for same commit (JENKINS-25639)
Version 2.3.2 (Dec 19, 2014)
Use git client plugin 1.13.0 (CVE-2014-9390)
Version 2.2.10 (Dec 19, 2014)
Use git client plugin 1.13.0 (CVE-2014-9390)
Do not continuously build when polling multiple repositories (JENKINS-25639)
Version 2.3.1 (Nov 29, 2014)
Add a build chooser to limit branches to be built based on age or ancestor SHA1
Update to git-client-plugin 1.12.0 (includes JGit 3.5.2)
Allow polling to ignore detected changes based on commit content
Do not continuously build when polling multiple repositories (JENKINS-25639)
Expand parameters on repository url before associate one url to one credential (JENKINS-23675)
Expand parameters on branch spec for remote polling (JENKINS-20427, JENKINS-14276)
Fix Gitiles file link for various Gitiles versions (JENKINS-25568)
Fixed notifyCommit builddata (JENKINS-24133)
Improve notifyCommit message to reduce user confusion
Version 2.2.9 (Nov 23, 2014)
Added behavior: "Polling ignores commits with certain messages"
GIT_BRANCH set to detached when sha1 parameter set in notifyCommit URL (JENKINS-24133)
Version 2.2.8 (Nov 12, 2014)
Add submodule update timeout as an option (JENKINS-22400)
Update Gitlab support for newer Gitlab versions (JENKINS-25568)
No exception if changeset author can't be found (JENKINS-16737 and JENKINS-10434)
Annotate builddata earlier to reduce race conditions (JENKINS-23641)
Pass marked revision to decorate revision (JENKINS-25191)
Avoid null pointer exception when last repo or branch deleted (JENKINS-25313)
Allow retry by throwing a different exception during certain fetch failures (JENKINS-20531)
Do not require a workspace when polling multiple repositories (JENKINS-25414)
Version 2.3 (Nov 10, 2014)
Released for Jenkins 1.568 and later, update center will exclude from earlier Jenkins versions
Do not require a workspace when polling multiple repositories (JENKINS-25414)
Version 2.3-beta-4 (Oct 29, 2014)
Update to JGit 3.5.1
Allow retry if fetch fails (JENKINS-20531)
Don't NPE if all repos and all branches removed from job definition (JENKINS-25313)
Correctly record built revision even on failed merge (JENKINS-25191)
Record build data sooner for better concurrency and safety (JENKINS-23641)
Do not throw exception if author can't be found in change set (JENKINS-16737, JENKINS-10434)
Version 2.2.7 (Oct 8, 2014)
Honor project specific Item/CONFIGURE permission even if overall Item/CONFIGURE has not been granted (SECURITY-158)
Save current build in BuildData prior to rescheduling (JENKINS-21464)
Fix GitPublisher null pointer exception when previous slave is missing
Expand variables in branch spec for remote polling (JENKINS-20427, JENKINS-14276)
Add GIT_PREVIOUS_SUCCESSFUL_COMMIT environment variable
Version 2.3-beta-3 (Oct 8, 2014)
Honor project specific Item/CONFIGURE permission even if overall Item/CONFIGURE has not been granted (SECURITY-158)
Save current build in BuildData prior to rescheduling (JENKINS-21464)
Fix GitPublisher null pointer exception when previous slave is missing
Expand variables in branch spec for remote polling (JENKINS-20427, JENKINS-14276)
Add GIT_PREVIOUS_SUCCESSFUL_COMMIT environment variable
Version 2.2.6 (Sep 20, 2014)
Add optional "force" to push from publisher (JENKINS-24082)
Support gitlist as a repository browser (JENKINS-19029)
Print the remote HEAD SHA1 in poll results to ease diagnostics
Add help describing the regex syntax allowed for "Branches to build"
Improve environment support which caused git polling to fail with "ssh not found" (JENKINS-24516, JENKINS-24467)
Pass a listener to calls to getEnvironment (JENKINS-24772)
Version 2.3-beta-2 (Sep 3, 2014)
Print remote head when fetching a SHA1
Assembla browser breaks config page (JENKINS-24261)
Recent changes is always empty in merge job (JENKINS-20392)
Polling incorrectly detects changes when refspec contains variable (JENKINS-22009)
Matrix project fails pre-merge (JENKINS-23179)
Add "Change log compare to branch" option to improve "Recent changes" for certain use cases
Add Assembla as supported source code and change browser support
Add Gitiles as supported source code and change browser support (android project git browser)
Return correct date/time to REST query of build date (JENKINS-23791)
Add timeout option to checkout (for slow file systems and large repos) (JENKINS-22400)
Expand parameters on repository url before evaluating credentials (JENKINS-23675)
Update to git-client-plugin 1.10.1.0 and JGit 3.4.1
Update other dependencies (ssh-credentials, credentials, httpcomponents, joda-time)
Version 2.2.5 (Aug 15, 2014)
Assembla browser breaks config page (JENKINS-24261)
Recent changes is always empty in merge job (JENKINS-20392)
Polling incorrectly detects changes when refspec contains variable (JENKINS-22009)
Matrix project fails pre-merge (JENKINS-23179)
Version 2.2.4 (Aug 2, 2014)
Add "Change log compare to branch" option to improve "Recent changes" for certain use cases
Add Assembla as supported source code and change browser support
Add Gitiles as supported source code and change browser support (android project git browser)
Return correct date/time to REST query of build date (JENKINS-23791)
Version 2.2.3 (Jul 31, 2014)
Add timeout option to checkout (for slow file systems and large repos) (JENKINS-22400)
Expand parameters on repository url before evaluating credentials (JENKINS-23675)
Update to git-client-plugin 1.10.1.0 and JGit 3.4.1
Update other dependencies (ssh-credentials, credentials, httpcomponents, joda-time)
Version 2.3-beta-1 (Jun 16, 2014)
Adapting to SCM API changes in Jenkins 1.568+. (JENKINS-23365)
Fixed advanced branch spec behaviour in getCandidateRevisions
includes/excludes branches specified using wildcard, and separated by white spaces.
Update to git-client-plugin 1.9.0 and JGit 3.4.0
option to set submodules update timeout (JENKINS-22400)
Version 2.2.2 (Jun 24, 2014)
Remote API export problem finally fixed (JENKINS-9843)
Version 2.2.1 (Apr 12, 2014)
Allow clean before checkout (JENKINS-22510)
Do not append trailing slash to most repository browser URL's (JENKINS-22342)
Fix null pointer exception in git polling with inverse build chooser (JENKINS-22053)
Version 2.2.0 (Apr 4, 2014)
Add optional submodule remote tracking if git version newer than 1.8.2 (JENKINS-19468)
Update to JGit 3.3.1
Fix javadoc warnings
Version 2.1.0 (Mar 31, 2014)
support sparse checkout if git version newer than 1.8.2 (JENKINS-21809)
improve performance when many branches are in the repository (JENKINS-5724)
retain git browser URL when saving job configuration (JENKINS-22064)
resolve tags which contain slashes (JENKINS-21952)
Version 2.0.4 (??? ??, 2014)
??? (tbd)
Version 2.0.3 (Feb 21, 2014)
fix the post-commit hook notification logic (according to SCMTrigger.html#isIgnorePostCommitHooks)
Version 2.0.2 (Feb 20, 2014)
option to configure timeout on major git operations (clone, fetch)
locks are considered a retryable failure
notifyCommit now accept a sha1 - make commit hook design simpler and more efficient (no poll required)
extend branch specifier (JENKINS-17417) and git repository URL
Better support for branches with "/" in name (JENKINS-14026)
Improve backward compatibility (JENKINS-20861)
Version 2.0.1 (Jan 8, 2014)
Use git-credentials-store so http credentials don't appear in workspace (JENKINS-20318)
Prune branch during fetch (JENKINS-20258)
Fix migration for 1.x skiptag option (JENKINS-20561)
Enforce Refsepc configuration after clone (JENKINS-20502)
Version 2.0 (Oct 22, 2013) - just in time for JUC :P
Refactored git plugin for UI to keep clean. Most exotic features now are isolated in Extensions, that is the recommended way to introduce new features
Introduce support for credentials (both ssh and username/password) based on credentials plugin
Version 1.5.0 (Aug 28, 2013)
Additional environmental values available to git notes
Extension point for other plugin to receive commit notifications
Support promoted builds plugin (passing GitRevisionParameter)
Do not re-use last build's environment for remote polling (JENKINS-14321)
Fixed variable expansion during polling (JENKINS-7411)
Added Phabricator and Kiln Harmony repository browsers, fixed GitLab URLs
Version 1.4.0 (May 13, 2013)
Avoid spaces in tag name, rejected by JGit (JENKINS-17195)
Force UTF-8 encoding to read changelog file (JENKINS-6203)
Retry build if SCM retry is configured (issue #14575)
Allow merge results to push from slave nodes, not just from master node (issue #16941)
Version 1.3.0 (March 12, 2013)
Fix a regression fetching from multiple remote repositories (JENKINS-16914)
Fix stackoverflow recursive invocation error caused by MailAddressResolver (JENKINS-16849)
Fix invalid id computing merge changelog (JENKINS-16888)
Fix lock on repository files (JENKINS-12188)
use default git installation if none matches (JENKINS-17013).
Expand reference parameter when set with variables
Expose GIT_URL environment variable (JENKINS-16684)
Branch can be set by a regexp, starting with a colon (pull request #138)
Version 1.2.0 (February 20, 2013)
- move git client related stuff into Git Client plugin
- double checked backward compatibility with gerrit, git-parameter and cloudbees validated-merge plugins.
Version 1.1.29 (February 17, 2013)
- fix a regression that breaks jenkins remoting
- restore BuildChooser API signature, that introduced JENKINS-16851
Version 1.1.27 (February 17, 2013)
- add version field to support new GitLab URL-scheme
- Trim branch name - a valid branch name does not begin or end with whitespace. (JENKINS-15235)
- set changeSet.kind to "git"
- Avoid some calls to "git show"
- Fix checking for an email address (JENKINS-16453)
- update Git logo icon
- Pass combineCommits to action (JENKINS-15160)
- expose previous built commit from same branch as GIT_PREVIOUS_COMMIT
- re-schedule project when multiple candidate revisions are left
- expand parameters in the remote branch name of merge options
GitAPI cleanup
Long term plan is to replace GitAPI cli-based implementation with a pure java (JGit) one, so that plugin is not system dependent.
- move git-plugin specific logic in GitSCM, have GitAPI implementation handle git client stuff only
- removed unused methods
- create unit test suite for GitAPI
- create alternate GitAPI implementation based on JGit
Version 1.1.26 (November 13, 2012)
- git polling mechanism can have build in infinite loop (JENKINS-15803)
Version 1.1.25 (October 13, 2012)
- Do "git reset" when we do "git clean" on git submodules (pull #100)
- NullPointerException during tag publishing (JENKINS-15391)
- Adds RhodeCode support (JENKINS-15420)
- Improved the
BuildChooserextension point for other plugins.
Version 1.1.24 (September 27, 2012)
- Shorten build data display name issue #15048
- Use correct refspec when fetching submodules issue #8149
- Allow a message to be associated with a tag created by the plugin
Version 1.1.23 (September 3, 2012)
- Improve changelog parsing for merge targets
- prevent process to hang when git waits for user to interactively provide credentials
- option to create a shallow clone to reduce network usage cloning large git repositories
- option to use committer/author email as ID in jenkins user database when parsing changelog (needed for openID / SSO integration)
- validate repository URL on job configuration
Version 1.1.22 (August 8, 2012)
- Fix regression for fully qualified branch name (REPOSITORY/BRANCH) JENKINS-14480
- Add support for variable expansion on branch spec (not just job parameters) JENKINS-8563
- Use master environment, not last build node, for fast remote polling JENKINS-14321
- run reset --hard on clean to take care of any local artifact
- normalize maven repository ID JENKINS-14443
Version 1.1.21 (July 10, 2012)
- Fixed support for "/" in branches names (JENKINS-14026)
- Fixed issue on windows+msysgit to escape "^" on git command line (JENKINS-13007)
Version 1.1.20 (June 25, 2012)
- Fixed NPE (JENKINS-10880)
- Fixed a git-rev-parse problem on Windows (JENKINS-13007)
- Use 'git whatchanged' instead of 'git show' (JENKINS-13580)
- Added git note support
Version 1.1.19 (June 8, 2012)
- restore GitAPI constructor for backward compatibility (JENKINS-12025)
- CGit browser support (JENKINS-6963).
- Handle special meaning of some charactes on Windows (JENKINS-13007)
- fixed java.lang.NoSuchMethodError: java/lang/String.isEmpty() (JENKINS-13993).
- Git icon(git-48x48.png) missing in job page. (JENKINS-13413).
- Git "Tag to push" should trim whitespace (JENKINS-13550).
Version 1.1.18 (released April 27, 2012)
- Loosened the repository matching algorithm for the push notification to better work with a repository with multiple access protocols.
Version 1.1.17 (released April 9, 2012)
- Fixed NPE in
compareRemoteRevisionWith(JENKINS-10880) - Improved the caching of static resources
notifyCommitendpoint now accept a comma delimited list of affected branches. Only the build(s) that match those branches will be triggered
Version 1.1.16 (released February 28, 2012)
- You can look up builds by their SHA1 through URLs like http://yourserver/jenkins/job/foo/scm/bySHA1/ab1249ab/ (any prefix of SHA1 will work)
- Perform environment variable expansion on the checkout directory.
- Support GitLab scm browser
- Support BitBucket.org scm browser
- option to set includes regions (JENKINS-11749)
- fix regression to deserialize build history (JENKINS-12369)
Version 1.1.15 (released December 27, 2011)
- Fixed a bug where the push notification didn't work with read-protected projects. (JENKINS-12022)
- Improved the handling of disabled projects in the push notification.
Version 1.1.14 (released November 30, 2011)
- Added support for instant commit push notifications (see also this blog post)
Version 1.1.13 (released November 24, 2011)
- option to ignore submodules completely (JENKINS-6658)
- support FishEye scm browser (JENKINS-7849)
- inverse choosing strategy to select all branches except for those specified (pull request #45)
- option to clone from a reference repository
- fix databinding bug (JENKINS-9914)
- action to tag a build, similar to subversion plugin feature
Version 1.1.12 (released August 5, 2011)
- When choosing the branch to build, Jenkins will pick up the oldest branch to induce fairness in the scheduling. (it looks at the timestamp of the tip of the branch.)
- Git now polls without needing a workspace (JENKINS-10131)
- Fixed the "no remote from branch name" problem (JENKINS-10060)
Version 1.1.11 (released July 22, 2011)
- Add support for generating links to Gitorious repositories. (https://github.com/jenkinsci/git-plugin/pull/38)
- Fixed DefaultBuildChooser logic (JENKINS-10408)
Version 1.1.10 (released July 15, 2011)
- Merge options persist properly now. (JENKINS-10270)
- Fixed NPE in PreBuildMergeOptions when using REST API. (JENKINS-9843)
- Global config name/email handle whitespace properly. (JENKINS-10272, JENKINS-9566)
- Improved memory handling of "git whatchanged". (JENKINS-8365)
- Excluded regions should now work with multiple commit changesets. (JENKINS-8342)
- ViewGit support added. (JENKINS-5163)
- Fixed NPE when validating remote for publisher. (JENKINS-9971)
- Tool selection persists now. (JENKINS-9765)
- Remote branch pruning now happens after fetch, to make sure all remotes are defined. (JENKINS-10348)
Version 1.1.9 (released May 16, 2011)
- Don't strip off interesting stuff from branch names in token macro (JENKINS-9510)
- Changes to serialization to support working with the MultiSCM plugin and general cleanliness. (github pull request)
- Check to be sure remote actually exists in local repo before running "git remote prune" against it. (JENKINS-9661)
- Eliminate a problem with NPEs on git config user.name/user.email usage on upgrades. (JENKINS-9702)
- Add a check for git executable version as 1.7 or greater before using --progress on git clone calls. (JENKINS-9635)
Version 1.1.8 (released May 6, 2011)
- Re-release of 1.1.7 to deal with forked version of plugin having already released with same groupId/artifactId/version as our 1.1.7 release, thereby breaking things.
Version 1.1.7 (released May 4, 2011)
- GIT_COMMIT environment variable now available in builds. (JENKINS-9253)
- Improved wording of error message when no revision is found to build. (JENKINS-9339)
- Added "--progress" to git clone call. (JENKINS-9168)
- Underlying error actually shown when git fetch fails. (JENKINS-9052)
- git config options for user.name and user.email now save properly. (JENKINS-9071)
- Properly handle empty string for branch when branch is parameterized. (JENKINS-8656)
- If no Jenkins user is found for a commit's user.name value, strip the username from "username@domain.com" from the user.email value and use that instead. (JENKINS-9016)
Version 1.1.6 (released Mar 8, 2011)
- Fix for warning stacktrace if paramaterized trigger plugin was not installed.
- No longer try to generate complete history as changelog if previous build's SHA1 no longer exists in repository. (JENKINS-8853)
- Fixed bug causing "Firstname Lastname@domain.com" to be used as email address for users. (JENKINS-7156)
- Passwords should now be properly used in https URLs. (JENKINS-3807)
- Exposed a few token macros
Version 1.1.5 (released Feb 14, 2011)
- Added an extension for Parameterized Trigger Plugin to allow Git SHA1 of the current build to be passed to downstream builds (so that they can act on the exact same commit.)
- Allowed optional disabling of internal tagging (JENKINS-5676)
- If specified, use configured values for user.email and user.name (JENKINS-2754)
- Removed obsolete/unused wipe out workspace option and defunct Gerrit build chooser.
- Rebranded to Jenkins!
Version 1.1.4 (released December 4, 2010)
- For Matrix projects, push only at the end of the whole thing, not at the configuration build (JENKINS-5005).
- Switching between browsers does not function properly (JENKINS-8210).
- Implement support for Redmine as browser.
Version 1.1.3 (released November 8, 2010)
- No changes except of updated version according to scm.
Version 1.1.2 (released November 8, 2010)
- Fixed major bug in polling (JENKINS-8032)
Version 1.1.1 (released November 5, 2010)
- Improved logging for failures with git fetch.
- Made sure .gitmodules is closed properly. (JENKINS-7659)
- Fixed issue with polling failing if the master has 0 executors. (JENKINS-7547)
- Modified Git publisher to run as late as possible in the post-build plugin order. (JENKINS-7877)
- Added optional call to "git remote prune" to prune obsolete local branches before build. (JENKINS-7831)
Version 1.1 (released September 21, 2010)
- Added ability for GitPublisher to only push if build succeeds. (JENKINS-7176)
- Fixed major bug with submodule behavior - making sure we don't try to fetch submodules until we've finished the initial clone. (JENKINS-7258)
- "Clean after checkout" wasn't invoked when pre-build merges were enabled. (JENKINS-7276)
- Form validation was missing for the GitPublisher tag and branch names, and an empty value was allowed for GitPublisher target repositories, leading to confusion. (JENKINS-7277)
- "Clean before build" will now run in submodules as well as root. (JENKINS-7376)
- When polling, Hudson-configured environment variables were not being used. (JENKINS-7411)
- Modifications to BuildData to deal with Hudson no longer serializing null keys. (JENKINS-7446)
- Support for --recursive option to submodule commands. (JENKINS-6258)
Version 1.0.1 (released August 9, 2010)
- Fixed submodules support - was broken by JENKINS-6902 fix. (JENKINS-7141)
- Switched "Recent Changes" list for a project to count changes per build, rather than using revision as if it were a number. (JENKINS-7154)
- Stopped putting problematic slash at end of GitWeb URL. (JENKINS-7020)
Version 1.0 (released July 29, 2010)
- Added support for Github as a repository browser.
- Added support for optionally putting source in a subdirectory of the workspace (JENKINS-6357)
- If all repository fetches fail, fail the build. (JENKINS-6902)
- Improved logging of git command execution errors (JENKINS-6330)
- 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 (released June 22, 2010)
- Fixed major bug in BuildChooser default selection and serialization (JENKINS-6827)
Version 0.9.1 (released June 22, 2010)
- Dramatic improvement in changelog generation, thanks to a switch to use "git whatchanged" (JENKINS-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.
Version 0.8.2
- Support for Gerrit plugin.
- Support for different build choosers.
Version 0.7.3
FIXME this changelog entry is incomplete! Please give me some love!
- Fixed JENKINS-2931, git tag freezing job execution (jbq)
- Improve log messages (jbq)
- Use build listener to report messages when pushing tags to origin (jbq)
- Fixed JENKINS-2762, fail to clone a repository on Windows (jbq)
Version 0.5
- Fix git plugin which was very broken when running on a remote server (magnayn)
- Fix NPE in GitChangeLogParser upon project's first build (jbq)
- Change workspace to a FilePath in GitAPI (jbq)
- Use git rev-list once instead of invoking git rev-parse indefinitely to find last build, see JENKINS-2469: GIT plugin very slow (jbq)
- Handle null-value of the repositories field to ensure backwards-compatibility with version 0.3,
ie when the project configuration is missing the <repositories/> XML element (jbq) - Improve error handling in revParse() (jbq)
- Fix handling of the "branch" configuration parameter (jbq)
- Improve tag handling, use show-ref instead of rev-parse to resolve the tag reference (jbq)
- Fix JENKINS-2675, Git fails on remote slaves (jbq)
Version 0.4 (never released)
- Allow multiple GIT repositories to be specified (magnayn)
- Allow submodule configurations to be generated on the fly (magnayn)
- Avoid infinite loops when git doesn't contains tags (david_calavera)
- Don't do a log of the entire branch if it's never been built (magnayn)
Version 0.3
- Add support for pre-build branch merges
Version 0.2
- Improve handling of git repositories (use local tags to identify up to date versions rather than the wc HEAD)
- Don't have to specify a branch, in which case all branches are examined for changes and built
- Includes a publisher which can be used to push build success/failure tags back up to the upstream repository
Version 0.1
- Initial Release
4025 Automation Way, Building C Suite 4N
141 Comments
Kohsuke Kawaguchi
Through rtyler: http://github.com/stephenh/git-central/blob/master/server/post-receive-hudson automates the set up of a Hudson job whenever a new branch is created. Nice.
jlongman -
How do I build a specific revision? I used to be able to specify a build should use SHA1-ID, like build
origin/bdbbfc3f0e9c57fbeff89de2ad7ca308a168575eand it would work. This is necessary for reproducibility.Has this changed? How do I do this now?
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:
http://www.electricsenator.net/2009/10/03/1254618530821.html
anthony dass
I would be very much interested in this tutorial but this link does't seems to work, do you have any alternate link? Thanks!
Unknown User (gtsimpson24)
Is it possible to use credentials when accessing a git repository? Or certificates?
Thanks,
Graeme
cemerick -
Is there any way to get the git plugin to checkout ref names instead of the sha's associated with remote refs? Not being on a branch in the course of a build is causing issues (for at least two of us) in conjunction with the M2 Release Plugin:
Can’t get automated release working with Hudson + Git + Maven Release Plugin
cemerick -
This issue has been resolved for me as of v0.8.0 of the git plugin. See my comment below.
Unknown User (david.antliff)
Really? I'm using 0.8 (by using the Hudson plugin upgrader) and still seeing Hudson check out a specific SHA-1 rather than a reference:
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: masterThe Git logs show it fetching the latest, then for some reason checking out the previous version with the sha, which puts it into *no branch. Then it does a git merge with the latest, still on *no branch. I've included the logs below.
I don't think this is the correct behavior given that I specify that I want to merge to the master branch. Thoughts? Bug?
Git logs from hudson:
git fetch /home/git/repositories/my_repo.git +refs/heads/master:refs/remotes/origin/mastergit ls-tree HEADgit rev-parse mastergit checkout -f old_rev_shahere's where it switches branchesgit merge new_rev_shacemerick -
I don't know if this is a bug, but +1 that this isn't correct behaviour IMO (see my comment directly above yours).
Unknown User (bradleyrobertson@gmail.com)
ya i read that. I'm also confused as to why it's using sha's, especially when the plugin allows you to specify the ref you want and the branch to merge to.
I personally do think it's a bug if you are specifying the branch to merge to and the fetched code is not merged to that branch
cemerick -
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.
Unknown User (david.antliff)
Brad: did you have any success with 0.8 in this respect? I'm seeing Hudson continue to check out the specific SHA rather than the branch reference, and therefore detach the HEAD.
Unknown User (bradleyrobertson@gmail.com)
To be honest, I haven't looked at this in quite some time, i'm working on a few projects so i've been fairly busy. I'll keep you posted when I find the time to see if this has been fixed for me.
anonymousultimo -
Problems with new 0.8 version under windows.
It looks very good and the new information about changed files is great but scm polling doesn't work anymore
jlongman -
I'm also having problems, but I'm not using windows:
Solved by adding executors to my master
Unknown User (david.antliff)
Is there an inconsistency here? This page says 0.8 is the Latest Release, but the download link to the .hpi file is pointing at 0.7.3.
What is the download link to the 0.8 hpi please, as I need to archive this file for static installation at my site.
Evgeny Goldin
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
Here's the full log and job's configuration
Git plugin passes null value for
GIT_BRANCHenvironment variable,which later fails in
MavenBuilder.java:156when Maven plugin callsSystem.getProperties().putAll(systemProps)Here's a debugger screenshot.
Evgeny Goldin
Fixed it by specifying
"master"as default branch, not empty and not"**".Posted it in my blog as well.
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.
Help!
-Mark
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 (miklernout)
This page should probably mention that the Git plugin relies on a recent version of the Git binaries (at least 1.7?).
Ian Eure
Same problem here with builds always starting from a detached HEAD. I'm using the most recent version of the plugin, 0.8.3.
My config is:
These are the git commands that get run:
It's not merging anything, and it's still checking out a SHA-1 instead of a symbolic branch name. What gives?
Unknown User (a. sparkowsky)
I'm trying to figure out how the tags generated by the plugin for each build are pushed back to the origin repository.
The text above mentions an option called 'Push GIT tags back to origin repository' but I'm not able to find it.
So how do I get the plugin pushing the tags for each build to the upstream repo?
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.
Here's the log output;
------------------
Started by user ITDude
Checkout:workspace / /home/hudson/jobs/TestHudson/workspace - hudson.remoting.LocalChannel@f74f6ef
Using strategy: Default
Checkout:workspace / /home/hudson/jobs/TestHudson/workspace - hudson.remoting.LocalChannel@f74f6ef
GitAPI created
Fetching changes from the remote Git repository
Fetching upstream changes from git@git.mycomp.com:test_hudson.git
workspace $ /usr/bin/git fetch -t git@git.mycomp.com:test_hudson.git +refs/heads/:refs/remotes/origin/
No protocol specified
(ssh-askpass:13369): Gtk-WARNING **: cannot open display: :0.0
Permission denied, please try again.
No protocol specified
(ssh-askpass:13370): Gtk-WARNING **: cannot open display: :0.0
Permission denied, please try again.
No protocol specified
(ssh-askpass:13371): Gtk-WARNING **: cannot open display: :0.0
Permission denied (publickey,password).
fatal: The remote end hung up unexpectedly
ERROR: Problem fetching from origin / origin - could be unavailable. Continuing anyway
ERROR: Nothing to do
Finished: FAILURE
========================
The key is definitely valid as I've tested it with a manual connection.
Unknown User (daleh)
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
Name of repository: origin/master
Refspec: I leave this blank and it generates the following: +refs/heads/:refs/remotes/origin/master/
I have also provided the Branches to build: master
I have tried many different combinations of settings, and each one gives a different error message, but none of them are ever getting to the point where Ant builds my simple Java project. On the above settings, I get the following log:
***
Started by user daleh
Checkout:workspace / /home/hudson/jobs/TestHudson/workspace - hudson.remoting.LocalChannel@3219ab8d
Using strategy: Default
Checkout:workspace / /home/hudson/jobs/TestHudson/workspace - hudson.remoting.LocalChannel@3219ab8d
GitAPI created
Fetching changes from the remote Git repository
Fetching upstream changes from git@git.mydomain.com:test_hudson.git
workspace $ /usr/bin/git fetch -t git@git.mydomain.com:test_hudson.git +refs/heads/:refs/remotes/origin/master/
error: unable to resolve reference refs/remotes/origin/master/master: Not a directory
From git@git.mydomain.com:test_hudson
! new branch master -> origin/master/master (unable to update local ref)
error: some local refs could not be updated; try running
'git remote prune git@git.mydomain.com:test_hudson.git' to remove any old, conflicting branches
ERROR: Problem fetching from origin/master / origin/master - could be unavailable. Continuing anyway
workspace $ /usr/bin/git tag -l master
workspace $ /usr/bin/git rev-parse origin/master/master
ERROR: Nothing to do
Finished: FAILURE
***
As for needing to remove any "old conflicting branches", I have none. This is a simple project with no conflicting branches.
Thanks in advance for any help provided
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)
Hello,
I have repoA and repoB, and i want clone repoA to directory for example workspace/myJob/A and clone repoB to workspace/myJob/B. Is it possible with this plugin ?
Daniel Blah
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
star latch
Try using Multiple SCMs plugin
Dave Abrahams
Having Serious Submodule Problems. I confess that I don't understand what the documentation above about automatic submodule handling is trying to convey about what Hudson is doing, but whatever it is, it seems to be wrong. I'm content to do the git submodule init / git submodule update myself if necessary. Log below; can you please help? Thanks!
Started by user dave
Checkout:workspace / /var/lib/hudson/jobs/Boost/workspace - hudson.remoting.LocalChannel@3faa7a6a
Using strategy: Default
Last Built Revision: Revision 9fc9270750b81ec49fb96ee7b37fde5547da67c7 (origin/master)
Checkout:workspace / /var/lib/hudson/jobs/Boost/workspace - hudson.remoting.LocalChannel@3faa7a6a
GitAPI created
Cloning the remote Git repository
Cloning repository origin
$ git clone -o origin git://gitorious.org/ryppl/boost.git /var/lib/hudson/jobs/Boost/workspace
Fetching upstream changes from git://gitorious.org/ryppl/boost.git
workspace $ git fetch -t git://gitorious.org/ryppl/boost.git +refs/heads/:refs/remotes/origin/
workspace $ git ls-tree HEAD
GitAPI created
Fetching upstream changes from git://gitorious.org/ryppl/boost.git/cmake/.git
cmake $ git fetch -t git://gitorious.org/ryppl/boost.git/cmake/.git +refs/heads/:refs/remotes/origin/
fatal: protocol error: expected sha/ref, got '
----------------------------------------------
Cannot find repository /ryppl/boost.git/cmake/.git
----------------------------------------------'
ERROR: Problem fetching from origin - could be unavailable. Continuing anyway
workspace $ git submodule init
workspace $ git submodule update
workspace $ git tag -l master
workspace $ git rev-parse origin/master
Commencing build of Revision 9fc9270750b81ec49fb96ee7b37fde5547da67c7 (origin/master)
GitAPI created
Checking out Revision 9fc9270750b81ec49fb96ee7b37fde5547da67c7 (origin/master)
workspace $ git checkout -f 9fc9270750b81ec49fb96ee7b37fde5547da67c7
workspace $ git submodule init
workspace $ git submodule sync
Fetching upstream changes from git://gitorious.org/ryppl/boost.git
workspace $ git fetch -t git://gitorious.org/ryppl/boost.git +refs/heads/:refs/remotes/origin/
workspace $ git ls-tree HEAD
GitAPI created
Fetching upstream changes from git://gitorious.org/ryppl/boost.git/cmake/.git
cmake $ git fetch -t git://gitorious.org/ryppl/boost.git/cmake/.git +refs/heads/:refs/remotes/origin/
fatal: protocol error: expected sha/ref, got '
----------------------------------------------
Cannot find repository /ryppl/boost.git/cmake/.git
----------------------------------------------'
ERROR: Problem fetching from origin - could be unavailable. Continuing anyway
workspace $ git submodule update
workspace $ git tag -a -f -m "Hudson Build #4" hudson-Boost-4
Recording changes in branch origin/master
workspace $ git whatchanged --no-abbrev -M --pretty=raw 9fc9270750b81ec49fb96ee7b37fde5547da67c7..9fc9270750b81ec49fb96ee7b37fde5547da67c7
Triggering default
Finished: FAILURE
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.
Patrick Renaud
I second that. Did you submit a JIRA for this yet?
Unknown User (john.firebaugh@gmail.com)
I would like to use the "pre-build branch merging" features mentioned, but I want hudson to either:
I work in an environment where `git pull --rebase` is preferred, so I don't want hudson cluttering up the commit history with its own merge commits.
Is there any way to accomplish this?
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):
You can see around the "warning: no common commits" that the plugin is fetching from the submodule (build-scripts.git)!
That's not right. Those new branches and tags are in the submodule but are being fetched into the parent. It shouldn't be doing this.
EDIT: new info - existing Hudson jobs from pre-upgrade work fine and the submodule tags are not 'merged' with the parent. But if I 'clear workspace' and rebuild any of them, they exhibit the incorrect behaviour noted above.
Unknown User (david.antliff)
How do I get 'permission' to create a new JIRA issue? I signed up for a dev.java.net account but when I click on the "create issue" link at the top of this page, JIRA tells me:
Errors
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'll also clarify that this bug is a regression - it was not present in version 0.8, introduced some time before (or at) 1.1. It is still present in 1.1.6.
Doug Reiland
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
Doug Reiland
Maybe somebody can give me step by step instructions.
I want hudson to trigger on changes, I have this working with post-receive hook in "global repository"
I want the development to push changes to temporary branches in "global repository", say like:
git push "global repository" HEAD:refs/heads/username/fixes
I want hudson to trigger, merge the changes into the "golden" branch from "global repository", build, and on success push changes back to golden branch on "global repository"
In addition, I want to delete the temporary branch in "global repository" as a post build step.
Ideally, I don't want hudson's push to golden to trigger another build.
Thanks!
Doug Reiland
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
Patrick Renaud
The latest release seems to be 1.1.3 but there is no corresponding entry for it in the Changelog section. How can we find out what's new in 1.1.3?
Unknown User (david.antliff)
What's a token macro? At the time of writing, the link in the Changelog for 1.1.6 goes to an empty wiki page.
anthony dass
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!
Lee Walton
I've added a wrapper around the git executable so that I can set up ssh-agent et al. However, I'm getting the following error when a build is executed:
The command executes fine outside of Jenkins.
The scripts used are as follows:
git-wrapper.sh:
add-ssh-key.sh:
#!/bin/bash SSH_ENV="$HOME/.ssh/environment" if [ -x /usr/bin/ssh-agent ] then SSH_AGENT=/usr/bin/ssh-agent SSH_ADD=/usr/bin/ssh-add else echo "Can't find ssh-agent" SSH_AGENT=/bin/false SSH_ADD=/bin/false fi start_agent () { printf "Starting new SSH agent... " $SSH_AGENT > "${SSH_ENV}" if [ $? = 0 ] then echo "OK" printf "3s|^echo|#echo|\nw\n\q\n" | ed "${SSH_ENV}" >/dev/null 2>&1 chmod 600 "${SSH_ENV}" . "${SSH_ENV}" else echo "ERROR" fi $SSH_ADD -l | grep : || { $SSH_ADD; } } # # Source SSH settings, if there # if [ -f "${SSH_ENV}" ]; then . "${SSH_ENV}" #ps ${SSH_AGENT_PID} doesn't work under cywgin ps -fu$LOGNAME | grep ${SSH_AGENT_PID}.*ssh-agent$ >/dev/null if [ $? != 0 ] then start_agent; else $SSH_ADD -l | grep : || { echo "Agent is running, but has no keys..." $SSH_ADD } fi else start_agent; fi ssh-add ~/.ssh/mygitkey >/dev/nullAny ideas?
Unknown User (david.antliff)
At a glance, it may be related to your git-wrapper script calling 'git $*' - that will split the tag "Jenkins Build #13 ..." into separate parameters - "Jenkins", "Build", "#13", etc.
Tim Gover
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.
Tim
Mike Jongejan
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.
Mike
Jason Zhang
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?
Thanks
Tim Dennison
I'm trying to set up a build using a remote branch named "feature/Configurations". I can't seem to find the right configuration for the git configuration for the build. Currently, I have:
URL of repository: git://server.domain/mve/mve.git
Branch Specifier: feature/Configurations
This configuration yields:
Does the GIT plugin support building remote branches?
Unknown User (david.antliff)
Try *origin/*feature/Configurations. Otherwise perhaps there's a problem with the plugin when the branch contains a / character.
Curtis Wilson
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??
Selected info from jenkins log:
INFO ------------------------------------------------------------------------
INFO BUILD SUCCESSFUL
INFO ------------------------------------------------------------------------
.....
channel stopped
ERROR: Failed to push merge to origin repository: Could not delete tag jenkins-spwebsite-release-18
Tony Peguero
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.
Jesse Cary
Just add an "Execute shell" script in the Build that sets a new variable that removes origin/
BRANCH=${GIT_BRANCH#origin/}Dane Powell
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...
Dane Powell
I ended up making my job parameterized with "BRANCH" as a string parameter, then I put $BRANCH for the branched specifier.
Mark MacVicar
I occasionally encounter an error in git clean on WIndows that I can't figure out. Jobs run fine for weeks then rarely have a problem removing a file:
hudson.plugins.git.GitException: Error performing command: C:\Program Files (x86)\Git\cmd\git.cmd clean -fdx
Command "C:\Program Files (x86)\Git\cmd\git.cmd clean -fdx" returned status code 1: Removing
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?
Tony Peguero
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.
Alexey Java
is it possible to fix bug
https://issues.jenkins-ci.org/browse/JENKINS-12316 ( git plugin should NOT tag every build by default )
in version 1.1.16? this is a blocker for us. we had to disable the build in Jenkins
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 ...
Thanks,
\Peter
Pascal Robert
Is there a way to use parameters with the local subdirectory for repo and the unique SCM name? If I set "Local subdirectory for repo" like this:
Projects/${PROJECT_NAME}I get:
Cannot run program "git" (in directory "/var/lib/jenkins/jobs/ERGroupware2/workspace/Projects/${PROJECT_NAME}"): java.io.IOException: error=2, No such file or directoryWould be useful to be able to use parameters value for the local name of the repo.
Kreislsepp .
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".
Bryan Rahn
I just upgraded to the latest GIT plugin, and am receiving this error when building my Xcode project, which has multiple submodules it needs to checkout and update: Commencing build of Revision b9279cd90472534862c412a72962b445a43228f8 (origin/master)
Checking out Revision b9279cd90472534862c412a72962b445a43228f8 (origin/master)
FATAL: Error performing command: git submodule update --init --recursive
Command "git submodule update --init --recursive" returned status code 1:
...
...
...
Please move or remove them before you can switch branches.
Aborting
Unknown User (ts@medical-insight.com)
I've found that using plink.exe from putty is 8-10 times faster than the ssh.exe that is shipped with msysGit. You can find a posting about the slowness of the shipped ssh.exe here: http://groups.google.com/group/msysgit/browse_thread/thread/c47054f2d14d0981
If you install putty before msysgit, the msysgit installer will give you an option to use plink.exe from putty instead of the shipped ssh.exe.
Johnny Kauffman
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:
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.
Chuck Reeves
Rather then dealing with all that local user messiness on windows, Just set the server to run as your user:
This way it will use your home directory with your ssh keys.
Ruth Morgenstein
I just upgraded from 1.1.21 to 1.1.25 and ALL of my jobs that poll github decided that there were changes. The git build messages are identical in the build before the upgrade and the build after.
Here is my console output - I notice that it has no idea what the 'last built revision' was:09:41:22 Started by an SCM change
09:41:22 Building remotely on i-e934d195 in workspace /mnt/jenkins/workspace/branch-2-community-junit-U10.04-master
09:41:22 Checkout:branch-2-community-junit-U10.04-master / /mnt/jenkins/workspace/branch-2-community-junit-U10.04-master - hudson.remoting.Channel@2a860bf4:i-e934d195
09:41:22 Using strategy: Default
09:41:22 Fetching changes from 1 remote Git repository
09:41:22 Fetching upstream changes from git@github.com:VoltDB/voltdb.git
09:41:23 Commencing build of Revision caf5be16caf652540da96c5237ea397a55276ab4 (origin/master)
09:41:23 Checking out Revision caf5be16caf652540da96c5237ea397a55276ab4 (origin/master)
09:41:23 Cleaning workspace
09:41:23 Resetting working tree
09:41:24 No change to record in branch origin/master
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.
michael d
With the svn plugin, when checking out code from the repository the console log would show which files are being checked out.
With git plugin I only get a summary but can't see the files as they are pulled. Is there a way to enable this functionality in the git plugin as well ? (maybe 'verbose' flag or something ?)
Thanks.
Jamil Ahmed
@michael d
Did you ever find a solution to this? I'm interested in knowing.
Scott Armit
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?
Any help is appreciated.
Thank you.
Yimin Li
Thanks for the plugin.
Michael Powell
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.
Thank you...
Regards,
Michael
Philipp Schneider
Hello,
we have an issue with the name of the branch. We have the git-flow pattern name and there we have a branch named
feature/PROJECT-4011-SomeCoolFeature
Seems like there is an issue with a branch name containing a "/".
Anybody else having the same issue?
Kailash Yadav
Hello,
Is there way to get list of file changes from last build?
My requirement :
I have 3 ant scripts and only one script should be execute, which is depend on changed file/folder.
for eg:
if path/to/my/project/package1/* changed -> execute build1.xml.
if path/to/my/project/package2/* *changed -> execute *build2.xml.
if path/to/my/project/package3/* *changed -> execute *build3.xml.
Thanks
Jamil Ahmed
@Kailash
Di you ever find a solution for your problem?
Zaraki Kenpachi
Hello,
why it isn't possible to use the variables of matrix build in the git plugin?
Max Spring
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/".
Max Spring
Turning off option "Clean after checkout" and putting this into a prebuild step does the trick:
( set +x git clean -n -xfd \ | grep -v ' \.repository/' \ | while read f; do \ p=${f#Would remove } (set -x; rm -rf $WORKSPACE/$p) done ) rm -rf $WORKSPACE/.repository/org/example/my/group/id/whateverJeremy Rampon
Hello,
Is it possible to pass extra parameters to a job when using the notifyCommit url?
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.
Martin d'Anjou
There is since Git Plugin 2.4.0 on July 18, 2015, see https://issues.jenkins-ci.org/browse/JENKINS-27902.
I do not know how to use it yet.
Vlad Aginsky
Hi all,
I want to detect and build tags from only one specific branch, and I don't know exactly what the tag string will look like.
Do you know how to configure git plugin for this?
I read this:
http://erics-notes.blogspot.co.il/2013/05/jenkins-build-latest-git-tag.html
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.
Adarsh R
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 EmailGIT_COMMITTER_EMAIL- Committer/Author EmailI 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?
Thanks,
Adarsh
Alexander Komarnitskiy
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?
sam detweiler
Using master/slave, I have a job that runs manually on the slave and builds a specific branch.
I now want to run this on a poll schedule.. change job config, turn on Poll SCM.
polling log shows
[poll] last built revision....
git ls-remote ....
cannot run program "git: Create Process error =2, cannot find file
this slave is linux, but that error is from windows (the master machine)
where does this polling status command run?
git is not installed on the master.
sam detweiler
the repo is specified as
git@server:reponame
Installed git on windows from http://git-scm.com/download/win
configured in path
restarted jenkins
now scm polling fails
using GIT_SSH to set credentials for the git user
error: failed to record SCM polling for hudson.maven.MavenModuleSet@.....
java.lang.RuntimeException: git plugin only support official git client http://git-scm.com/download/win
org.jenkins.plugins.gitclient.CliGitAPIImpl.createWindowsGitSSH(CliGitAPIImpl.java:1271)
what did we do wrong?
if I remove the git@
the poll works correctly with the credentials specified under the repo url
but the build now fails with access denied
we originally specified the SSH agent and no credentials to get build to work
there is no 'git' user on the linux build machine, nor on the windows master
Yu Teng Lei
If there are multiple branches, would the default checkout strategy always pick one of the specified branch with the latest commit?
Unknown User (thomas.oeding@rtt.ag)
my logs shows many messages like:
(latest git plugin is installed)
how can i get rid of them?
Orgad Shaneh
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).
Is there a way to achieve this?
JIVESH PT
I have freestyle project job. In that job i want to merge data from one git branch to another. I have tried GIT Plugin. Can you please help this?
sam detweiler
In the advanced section, I had one comment about
>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.
for us there are different actual builds for different phases of the project. leaving the branch field empty runs THIS build on any changed branch, including the 'upstream' branch integration.
also, there are different projects in the teams repo, that use different pom files (changes in the nodejs ui code do not need to recompile or test all of the server side code).
I have a post-receive hook that does all this decision work, ignores changes on specific branches (master, intergration, ... team specific), and starts the maven build in the right project.
I don't see how to accomplish this using the selective branch build & merge function described here. (sort of against polling the repo in general too)
Darrel Vuncannon
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?
Regards,
Darrel V.
Cary, North Carolina
sam detweiler
running Jenkins 1.554.2.2, and git plugin 2.2.7.
we have multiple repos being worked by the same team, and are using a single common job to build & merge developer changes
like this Using Git, Jenkins and pre-build branch merging, but using build triggering using the buildwithparameters plugin uri request string to pass parms.
(i've documented above problems with polling and passing parms)..
all this works great.
now we need to build the code in the repos.. we only want to build the changed code across all the repos, so I have a freestyle job which runs a script to check
for changes to the repo since last check. (does build periodically).
then we use a conditional to actually start the build job for this component.
both the change checker and the repo builder are a single jobs (freestyle and maven), which execute the same process across the repos.
they take git server, repo, branch,
so I start up 4 checkers at one time, same jenkins job, different parms.
they each kick off a single job, passing on parms
today ran into a new problem..
jenkins job B, repo fred got last revision 3456
jenkins job A, repo mary, got last revision 12345
jenkins job C, repo sue, got last revision 12345, and failed, cause 12345 is the last revision in repo mary.
runnig git commands from the jenkins agent commandline shows all the correct revisions in the repo sue.
but the build continues to try to pull the 12345 revision...
it looks like the revision built is passed between jobs of the same name. the job is NOT configured to wipe the clone workspace, as my last revision checking file is stored there.
there will be 10 or 12 repos that need to be built the same way, so I want to use 1 job and pass it parms.
I deleted the prior job which had the failing revision recorded as its change revision, and the problem went away. for the moment..
worried about when it will appear again
sam detweiler
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).
doesn't exist on my lastest jenkins 1.592, git plugin 2.3.1
I have git publisher as a post build action.
ying zhang
today i use the version 2.3.2 git plugin and centos system jenkins-1.595-1.1.noarch.rpm ,and i got that:
Cloning the remote Git repository
Cloning repository git@scmgit.staff.xdf.cn:educationservice/ucan1v1.git
> git init /neworiental/data/jenkins_workspace/workspace/Ucan1V1 # timeout=10
Fetching upstream changes from git@scmgit.staff.xdf.cn:educationservice/ucan1v1.git
> git --version # timeout=10
using GIT_SSH to set credentials gitlab user
> git -c core.askpass=true fetch --tags --progress git@scmgit.staff.xdf.cn:educationservice/ucan1v1.git +refs/heads/*:refs/remotes/origin/*
ERROR: Error cloning remote repo 'origin'
ERROR: Error cloning remote repo 'origin'
Finished: FAILURE
Cloning the remote Git repository
Cloning repository git@scmgit.staff.xdf.cn:educationservice/ucan1v1.git
> git init /neworiental/data/jenkins_workspace/workspace/Ucan1V1 # timeout=10
Fetching upstream changes from git@scmgit.staff.xdf.cn:educationservice/ucan1v1.git
> git --version # timeout=10
using GIT_SSH to set credentials gitlab user
> git -c core.askpass=true fetch --tags --progress git@scmgit.staff.xdf.cn:educationservice/ucan1v1.git +refs/heads/*:refs/remotes/origin/*
ERROR: Error cloning remote repo 'origin'
ERROR: Error cloning remote repo 'origin'
Finished: FAILURE
***************************************************************
git -c why i can't find “-c” in git command ?
Faisal Rabbani
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.
http://server/jenkins/git/notifyCommit?url=git@bitbucket.org:myrepogit\[&branches=dev\]
Gives Response:
No git jobs using repository: git@bitbucket.org:myrepo,git[ and branches: dev]
No Git consumers using SCM API plugin for: git@bitbucket.org:myrepo.git[
http://jenkins/git/notifyCommit?url=https://bitbucket.org/myrepo
works fine and triggers build but as soon as I mention branch in url like:
http://server/jenkins/git/notifyCommit?url=git@bitbucket.org:myrepogit\[&branches=dev\]
No git jobs using repository: git@bitbucket.org:myrepo,git[ and branches: dev]
No Git consumers using SCM API plugin for: git@bitbucket.org:myrepo.git[
Faisal Rabbani
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.
[http://server/jenkins/git/notifyCommit?url=git@bitbucket.org:myrepogit[&branches=dev]]
Gives Response:
No git jobs using repository: git@bitbucket.org:myrepo,git[ and branches: dev]
No Git consumers using SCM API plugin for: git@bitbucket.org:myrepo.git[
http://jenkins/git/notifyCommit?url=https://bitbucket.org/myrepo
works fine and triggers build but as soon as I mention branch in url like:
http://server/jenkins/git/notifyCommit?url=git@bitbucket.org:myrepogit\[&branches=dev\] ;
No git jobs using repository: git@bitbucket.org:myrepo,git[ and branches: dev]
No Git consumers using SCM API plugin for: git@bitbucket.org:myrepo.git[
Jamil Ahmed
Is it possible to show the code changes every time it pulls in the console log?
Andy Johns
Suddenly git polling has stopped working, on all projects. Running Jenkins ver. 1.596.1, Git plugin 2.3.5 and Git Client plugin 1.16.1
My project configuration branch specifier is: refs/heads/develop
Git polling log looks like:
Polling always says "No Changes" even though changes have been made.
Running the command > /usr/local/git/bin/git -c core.askpass=true ls-remote -h ssh://myuser@mygiturl.mycompany.com/gitroot/myproject # timeout=10
in an SSH shell gives me output like:
I'm stumped. Anyone have a suggestion?
Thanks
Mark Waite
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.
Andy Johns
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.
Thanks for the help!
Martin d'Anjou
What does it mean to be "worthy of a build"?
I don't understand this line:
Solving JENKINS-27902 (Allow to pass additional request parameter for notifyCommit) means that additional parameters can be passed to the Git Plugin... but:
Gaurav Negi
I am using git plugin 2.3.5 in Jenkins.
When I close the code from GIT plugin, it donot retain the upstream branch name
Running following command on cloned code gives me this.
*_$ git rev-parse --abbrev-ref @
_*
error: No upstream branch found for ''
*_@
_*
error: No upstream branch found for ''
*_fatal: ambiguous argument '@
': unknown revision or path not in the working tree._*
Use '--' to separate paths from revisions
However when I manually clone the code and run this command this gives me expected output.
*_$ git rev-parse --abbrev-ref @
_*
origin/master
Any idea, what I am missing with the GIT plugin?
Paulo Moreira
Greatings,
I am facing git clone errors, via git plugin under Windows:ERROR: Error fetching remote repo 'origin' .....status code 128:
stdout:
stderr: plink: unknown option "-o"
plink: unknown option "-p"
fatal: Could not read from remote repository.
This runs as slave:
GIT client plugin: 1.19.0
Git plugin: 2.4.0
Jenkins: 1.639
Please note: under Execute Windows batch command its OK
It only fails under GIT Plugin (Source Code Management)
m r
Hi. Can I use Git plugin to connect to Git repository on Team Foundation Server 2013? When I enter repository URL in Jenkins, I get exception:
returned status code 128:
stdout:
stderr: fatal: http://<host>/tfs/DefaultCollection/_git/<project>/info/refs not valid: is this a git repository
Please help me.
Kevin Navero
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 $
/../../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?
Kevin Navero
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."
Kevin Navero
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.
Dan Beachler
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"
michael giroux
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 Environment Variables section does not list GIT_LOCAL_BRANCH.
mgy tdxmgy
The git plugin in hudson can config one git repository url and its local directorys, then another git repository url and its local directorys, but just one local dir in jenkins, so when it will support in jenkins?
mgy tdxmgy
The git plugin in hudson can config one git repository url and its local directorys, then another git repository url and its local directorys, but just one local dir in jenkins, so when it will support in jenkins?
Mark Waite
The Jenkins git plugin won't add support for multiple repositories in a single workspace. Use the Jenkins pipeline instead.
asd asd
Two questions:
1. I've get an error when entering the repository URL:
"Failed to connect to repository : Command "/tools/git/bin/git -c core.askpass=true ls-remote -h user@our.git.com:repos HEAD" returned status code 128:
stdout:
stderr: fatal: failed to stat '.': Permission denied"
I found this: https://issues.jenkins-ci.org/browse/JENKINS-29406, but still cannot understand, which directory permissions needs to be checked: /tools/git/bin/git OK, plugins/git-client OK, workspace OK, ~ OK.
From which location this command tries to launch?
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?
B Hicks
Hello,
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.
Example output showing a specific revision being checked out:Checking out Revision 3195b1802ee464fe353b814ce1860b079d97db85 (refs/remotes/origin/master)
> git.exe config core.sparsecheckout # timeout=10
> git.exe checkout -f 3195b1802ee464fe353b814ce1860b079d97db85
michael giroux
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'.
Michael
B Hicks
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.
michael giroux
Wish I could be more help. That configuration works exactly as we would expect here at my company.
Might be able to offer a bit more help if you posted the exact console messages that indicate a failure.
Mark Waite
Sorry that I didn't see your question earlier.
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.
Bella N
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?
Mark Waite
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.
Sivaram Yadala
The option "Use credentials from default remote of parent repository" which existed in "Advanced sub-module behaviors" is absent in this version. Any reason for this?
Mark Waite
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.
Vitaly Karasik
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?
In we log we see the following:
> git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
> git config remote.origin.url ssh://git@stash.example.com/myrepo/frontend.git # timeout=10
Cleaning workspace
> git rev-parse --verify HEAD # timeout=10
Resetting working tree
> git reset --hard # timeout=10
> git clean -fdx # timeout=10
Fetching upstream changes from ssh://git@stash.example.com/myrepo/frontend.git
> git --version # timeout=10
......
Checking out Revision 62c8703236bd0ce295b28fgfdshsfdg7722f577 (origin/feature/some-branch)
Mark Waite
That sounds like a bug and would need more investigation (since I've not seen that behavior). This submit a bug report to the Jenkins bug tracker.
Vitaly Karasik
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.
Mark Waite
Branch name is remembered in the job definition. The job definition persists even if the workspace is removed
Vitaly Karasik
Thank you!
Do you mean even after I replaced branch name, the previous one is still in the job definition?
Didn't know about that.
Mark Waite
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.
Vitaly Karasik
Agree, it's that I think.
I meant - "where Jenkins/Gitplugin remember the *previous* branch details?
Mark Waite
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.
Omar H
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 ?
Omar H
future release*
Mark Waite
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.
minho k
I've used Git SCM with Additional Behaviors(Check out to a sub-directory).
Why are created two directory?
(ex. test, test@tmp)
What is directory "...@tmp"?
Mark Turner
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?
Stephen Connolly
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
SCMHeadthat does not implementTagSCMHeadand 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")The correct implementation of tag support is planned, but there are multiple blockers. The biggest blocker is probably JENKINS-45502 - Getting issue details... STATUS though we could probably special-case around that for tags, my preference would be to address it in that context. In case you are wondering, the intent is to add support for tags... (I even left a placeholder or two at the appropriate points, e.g. https://github.com/jenkinsci/git-plugin/blob/c8b33bbec2e091fbac9500e8a292a7529ba4b360/src/main/java/jenkins/plugins/git/AbstractGitSCMSource.java#L399-L404 and in fact adding https://github.com/jenkinsci/git-plugin/blob/c8b33bbec2e091fbac9500e8a292a7529ba4b360/src/main/java/jenkins/plugins/git/traits/BranchDiscoveryTrait.java was specifically to enable adding a tag discovery trait at some point without surprising users) ... but we need to finish preparing the groundwork first or else lots of users will be surprised by build storms, etc)
Mark Turner
Thanks for the clear answer!
Add Comment