-
Bug
-
Resolution: Fixed
-
Major
-
Linux Ubuntu 13.04
Apache Tomcat/7.0.35
Jenkins 1.549
git-client plugin 1.6.2
GitLab 6.1.0
Gitlab is running on the same linux server under a different sub-domain & different linux user name.
-
Powered by SuggestiMate
When I upgraded the git-client plugin from 1.6.1 to 1.6.2, a project now builds every time it polls the SCM (a GitLab repo) even if the version hash is identical.
Some jobs indicate that there is a problem and "could not remove the credential section from the git configuration" (see below polling log sample). But even these jobs build on every SCM poll even when the git version has has not changed. Below, I have 8 builds in a row that all reference the same revision, and all say "changes found."
======================
Started on Feb 4, 2014 5:53:33 PM
Using strategy: Default
[poll] Last Built Revision: Revision 1c8eda4fa98b092973c7dfe3b3c1d6c859971922 (origin/MASTER)
using .gitcredentials to set credentials
Could not remove the credential section from the git configuration
Done. Took 0.52 sec
Changes found
[JENKINS-21652] Building at each git-client polling interval even when no changes present
Would you be willing to install a more verbose logging unreleased version of git-client-plugin to help isolate the problem? I think the polling may be hiding an exception (possibly hinted by the "could not remove the credential section", but there are several places in that polling code which might throw the exception and a more verbose logging plugin would help isolate which case you're seeing.
That more verbose git-client-plugin doesn't exist yet. I'll only create it if you're willing to use it to diagnose the problem further.
Absolutely!
Just point me to where to get it, or alternately, give me the repo URL and the maven build command and I'll build it.
If you can build the branch https://github.com/MarkEWaite/git-plugin/tree/proto-additional-logging-in-GitSCM , that adds a few additional log messages in the area of code where I think things are most likely to be failing.
Ignore previous version of this comment.
Build succeeded, which .jars / artifacts that were built are needed for this custom git-client-plugin? Forgive my ignorance, I've never installed a custom compiled plugin before.
==============================
[INFO] Installing c:\dev\jenkins\workspace\Git-Client-Plugin\target\git.hpi to C:\.m2\repository\org\jenkins-ci\plugins\git\2.0.2-SNAPSHOT\git-2.0.2-SNAPSHOT.hpi
[INFO] Installing c:\dev\jenkins\workspace\Git-Client-Plugin\pom.xml to C:\.m2\repository\org\jenkins-ci\plugins\git\2.0.2-SNAPSHOT\git-2.0.2-SNAPSHOT.pom
[INFO] Installing c:\dev\jenkins\workspace\Git-Client-Plugin\target\git.jar to C:\.m2\repository\org\jenkins-ci\plugins\git\2.0.2-SNAPSHOT\git-2.0.2-SNAPSHOT.jar
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 20.998s
[INFO] Finished at: Wed Feb 05 19:56:18 MST 2014
[INFO] Final Memory: 45M/505M
[INFO] ------------------------------------------------------------------------
Finished: SUCCESS
Seems like I have the correct version installed, but the polling log does not display any more information than before.
I set polling to "* * * * *" to poll SCM (gitlab) every minute. No changes were made to the repo.
Below are the polling log output from the builds that are kicked off every minute.
=================================
Started on Feb 5, 2014 8:13:16 PM
Using strategy: Default
[poll] Last Built Revision: Revision 1c8eda4fa98b092973c7dfe3b3c1d6c859971922 (origin/MASTER)
using .gitcredentials to set credentials
Done. Took 0.52 sec
Changes found
=================================
Started on Feb 5, 2014 8:12:16 PM
Using strategy: Default
[poll] Last Built Revision: Revision 1c8eda4fa98b092973c7dfe3b3c1d6c859971922 (origin/MASTER)
using .gitcredentials to set credentials
Done. Took 0.51 sec
Changes found
=================================
Started on Feb 5, 2014 8:11:16 PM
Using strategy: Default
[poll] Last Built Revision: Revision 1c8eda4fa98b092973c7dfe3b3c1d6c859971922 (origin/MASTER)
using .gitcredentials to set credentials
Done. Took 0.55 sec
Changes found
=================================
Started on Feb 5, 2014 8:10:16 PM
Using strategy: Default
[poll] Last Built Revision: Revision 1c8eda4fa98b092973c7dfe3b3c1d6c859971922 (origin/MASTER)
using .gitcredentials to set credentials
Done. Took 0.51 sec
Changes found
After you uploaded the new git.hpi file through the Advanced tab on the Manage Plugins page, did you restart Jenkins so that the new version of the plugin would be active?
If not, you need to do that.
If you did, and it is showing exactly those messages, then I'll probably need to insert more logging statements to see the location where the code is reaching during execution.
Polling still works when polling a Github project:
Polling Log:
================================
Started on Feb 5, 2014 8:34:16 PM
Using strategy: Default
[poll] Last Built Revision: Revision 59ad27cc4726f4fe1d19c438f3b77d3c53255086 (origin/master)
using .gitcredentials to set credentials
Done. Took 1.5 sec
No changes
================================
Here is a snipit of pulling down the main jenkinsci project from github:
================================
Started by user xxxxxxxxxxxxx
Building remotely on xxxxxxxxxxxxx in workspace c:\dev\jenkins\workspace\Build Jenkins
Fetching changes from the remote Git repository
Fetching upstream changes from https://github.com/jenkinsci/jenkins.git
using .gitcredentials to set credentials
Checking out Revision 59ad27cc4726f4fe1d19c438f3b77d3c53255086 (origin/master)
[Build Jenkins] $ cmd /c call C:\WINDOWS\TEMP\hudson5265730787398879415.bat
c:\dev\jenkins\workspace\Build Jenkins>exit 0
Finished: SUCCESS
Yes I restarted jenkins, so unfortunately that isn't the culprit.
Restarted via its own plugin manager's restart checkbox and via tomcat (reload the context).
I've made further additions to the logging that I will push onto that branch. One of the changes is to modify the last built revision message so that there is clear evidence that your jenkins instance is executing the plugin with the additional logging.
A new version has been pushed to that branch. Could you build again and deploy it?
The new version should report "last built version" instead of "Last Built Version".
I see the case changes, so I am now using the new version, but no additional logging information is displayed. Is there a jenkins / tomcat flag I need to enable for more debug info?
Polling log with updated plugin correctly found changes:
======================================
Started on Feb 6, 2014 11:23:08 AM
Using strategy: Default
[poll] Last Built Revision: Revision 1c8eda4fa98b092973c7dfe3b3c1d6c859971922 (origin/MASTER)
using .gitcredentials to set credentials
Done. Took 0.52 sec
Changes found
======================================
The build sees the new version and completes:
======================================
Started by an SCM change
Building remotely on xxxxxxxxxxx in workspace c:\dev\jenkins\workspace\Deploy to xxxxxxxxxxx via Git
Fetching changes from the remote Git repository
Fetching upstream changes from http://lab.xxxxxxxxxxx.com/jason/ioix.git
using .gitcredentials to set credentials
Checking out Revision 0efb8084ff48a660d6bee48e420cadfaf41c42f8 (origin/MASTER)
======================================
Note the new Revision is identified.
But unfortunately, the next polling interval (1min), it still thinks there are changes, and it builds again. Is the current version not getting stored for reference?
======================================
Started on Feb 6, 2014 11:24:08 AM
Using strategy: Default
[poll] Last Built Revision: Revision 0efb8084ff48a660d6bee48e420cadfaf41c42f8 (origin/MASTER)
using .gitcredentials to set credentials
Done. Took 0.52 sec
Changes found
======================================
Started by an SCM change
Building remotely on xxxxxxxxxxx in workspace c:\dev\jenkins\workspace\Deploy to xxxxxxxxxxx via Git
Fetching changes from the remote Git repository
Fetching upstream changes from http://lab.xxxxxxxxxxx.com/jason/ioix.git
using .gitcredentials to set credentials
Checking out Revision 0efb8084ff48a660d6bee48e420cadfaf41c42f8 (origin/MASTER)
======================================
Notice that the polling log's "last built" matches the build log's "checking out revision.."
That doesn't match what I expected. The line which says "[poll] Last Built Revision: Revision" should have said "[poll] last built revision: Revision".
Either there is another location in the code which is producing that same message, or I've missed actually making the change on that branch, or your checkout did not actually include that branch, or the installation did not actually include the built code. Unfortunately, my time will be limited to do further investigation because I need to do my day job and can only contribute to Jenkins on nights and weekends.
I completely understand. I will doublecheck the build of the git repo you linked, doublecheck the deployment to my jenkins server, etc and report back.
It looks like both builds were from the same revision: 49a2a30aeaf30151eec8da43e1cacfc9b89ad8a5, which is not the most recent version. That was the Feb4 checkin by De Loof (according to my Sourcetree copy of that repo link:
https://github.com/MarkEWaite/git-plugin.git
My jenkins system isn't pulling in the latest code off that fork for some reason. So to eliminate my jenkins system, I built directly from my sourcetree clone of that repo using the same command. I deployed that 2.0.2 version to my jenkins server.
Then I repeated the test by enabling SCM polling. Again, I get the same message with the same letters upper case that you expected to see lower case.
Looks like I needed to be checkign out a different branch, not just master from that repo URL. I'll report back after I get my brain engaged and use the right branch.
Sorry for not being clear. My changes are definitely not on the master branch. They are on the branch https://github.com/MarkEWaite/git-plugin/tree/proto-additional-logging-in-GitSCM . You'll need to checkout that branch, something like:
git clone https://github.com/MarkEWaite/git-plugin.git cd git-plugin git checkout -b proto-additional-logging-in-GitSCM -t origin/proto-additional-logging-in-GitSCM mvn -DskipTests=true install
That should create target/git.hpi which you can upload with the additional logging.
Ok, with the correct version of git client installed I now see this message when turning on polling (it should not build because still no changes on this repo).
Started on Feb 6, 2014 5:11:42 PM
Using strategy: Default
[poll] Last built revision is Revision 0efb8084ff48a660d6bee48e420cadfaf41c42f8 (origin/MASTER)
[poll] fast remote polling preparing.
[poll] getting headRev.
using .gitcredentials to set credentials
[poll] headRev is null
[poll] head(null) != lastBuild(AnyObjectId[0efb8084ff48a660d6bee48e420cadfaf41c42f8])
Done. Took 0.48 sec
Changes found
thank you for your patience. I re-read your instructions and they were quite clear. I just brain-farted and forgot to include the branch.
That's a great result. Thanks very much. That says that the wrapper around the "git ls-remote -h" call is (incorrectly) returning null when it polls the remote repository. One work around would be to require a local workspace.
If you're still willing to experiment, I need you to login as the Jenkins user on your Jenkins master node, change to a completely empty directory outside of any git repository, and execute the command "git ls-remote -h your_url" where you replace your_url with the URL of your repository. I suspect it will report something of interest, though I'm not entirely sure what it will report.
I've also uploaded a minor addition trying to assure that the URL used by the plugin matches the URL you expect. If the git ls-remote command output does not surprise you, then download the latest change from that same branch, compile it, and install it. It will report the URL of the repository which git ls-remote is polling.
Output looks good. no surprises:
===================================
tomcat@XXXXXXXXXX:~/testing$ git ls-remote -h http://lab.XXXXXXXXXX.com/jason/ioix.git
Username for 'http://lab.XXXXXXXXXX.com': jason@XXXXXXXXXX.com
Password for 'http://jason@XXXXXXXXXX.com@lab.XXXXXXXXXX.com':
5bc93624698780e7faf7dff1931882d824b009b5 refs/heads/XXXXXXXXXX
6a86d86b943dcd7a6044862d17bdebabdc1e993a refs/heads/XXXXXXXXXX
1ac0baa92afb0695675e40374d06c3b9353bb80f refs/heads/XXXXXXXXXX
36999ebc0cd3ed2b4059f06a38be97a11a56a452 refs/heads/XXXXXXXXXX
tomcat@XXXXXXXXXX:~/testing$
===================================
When you pasted that output, were the "Username for" line and the "Password for" line both in the output?
I'm not sure how the git ls-remote parser will handle that output. I'll need to do more investigation in the source code this weekend. I think it expects a 40 character SHA1 followed by white space followed by the branch name.
That command was run from the linux server with out the aid of a credential store reference, so I had to authenticate to the server. That shouldn't be present if using a git command that makes use of the jenkins credential store.
We're seeing this exact same problem with 1.609.1 and git plugin 2.3.5. We have polling configured on a job to look every 3 hours, and it builds every time even if there are no changes.
We are not using the fast remote polling, because we are trying to use the include/exclude feature to limit triggers to a subset of files in the project.
One thing that may be contributing to this is that the last build revision is listed as refs/remotes/origin/branch instead of refs/heads/branch. It's not clear what command is being used when performing the poll, but git ls-remote -h <url> never returns anything for refs/remotes/origin, only refs/heads.
wsaxon I've been seeking a way to repeatably show a "builds on every poll" bug that I had seen while testing the pre-release of git plugin 2.3.6. While seeking repeatable steps for the "builds on every poll" bug that I had seen, I found that for the case I was trying, 2.3.4 was better behaved than 2.3.5.
Would you be willing to try the same sequence of steps with the 2.3.4 git plugin to see if that isolates the problem to specifically the changes between 2.3.4 and 2.3.5?
No problem, I just downgraded. Same behavior, although I triggered the poll using the Poll SCM Plugin's 'Poll Now' button.
I've included the relevant SCM and polling config below; most of our jobs use parameters and env-inject to set some generic stuff.
Our goal is to have pre-merge builds using the Gerrit trigger, and then QA builds on a timer only if code changes or the build is triggered by upstream. We could just use the Gerrit trigger for post-merge, but that ends up producing too many builds.
<scm class="hudson.plugins.git.GitSCM" plugin="git@2.3.4"> <configVersion>2</configVersion> <userRemoteConfigs> <hudson.plugins.git.UserRemoteConfig> <url>ssh://svc_jenkins_cm@${GERRIT}/${MASTER_REPO}</url> <credentialsId>9f9b349f-f711-46dc-98a6-dfc8e645abb8</credentialsId> </hudson.plugins.git.UserRemoteConfig> </userRemoteConfigs> <branches> <hudson.plugins.git.BranchSpec> <name>origin/${BRANCH}</name> </hudson.plugins.git.BranchSpec> </branches> <doGenerateSubmoduleConfigurations>false</doGenerateSubmoduleConfigurations> <browser class="hudson.plugins.git.browser.CGit"> <url>http://${GERRIT}/git/${MASTER_REPO}</url> </browser> <submoduleCfg class="list"/> <extensions> <hudson.plugins.git.extensions.impl.CloneOption> <shallow>false</shallow> <reference>${REFERENCE_PATH}\${MASTER_REPO}.git</reference> </hudson.plugins.git.extensions.impl.CloneOption> <hudson.plugins.git.extensions.impl.RelativeTargetDirectory> <relativeTargetDir>${MASTER_REPO}</relativeTargetDir> </hudson.plugins.git.extensions.impl.RelativeTargetDirectory> <hudson.plugins.git.extensions.impl.SparseCheckoutPaths> <sparseCheckoutPaths> <hudson.plugins.git.extensions.impl.SparseCheckoutPath> <path>/CM/Common</path> </hudson.plugins.git.extensions.impl.SparseCheckoutPath> <hudson.plugins.git.extensions.impl.SparseCheckoutPath> <path>/CM/build_name</path> </hudson.plugins.git.extensions.impl.SparseCheckoutPath> <hudson.plugins.git.extensions.impl.SparseCheckoutPath> <path>/DotNet/Common</path> </hudson.plugins.git.extensions.impl.SparseCheckoutPath> <hudson.plugins.git.extensions.impl.SparseCheckoutPath> <path>/DotNet/One</path> </hudson.plugins.git.extensions.impl.SparseCheckoutPath> <hudson.plugins.git.extensions.impl.SparseCheckoutPath> <path>/DotNet/Two</path> </hudson.plugins.git.extensions.impl.SparseCheckoutPath> <hudson.plugins.git.extensions.impl.SparseCheckoutPath> <path>/DotNet/StrongNameKey.snk</path> </hudson.plugins.git.extensions.impl.SparseCheckoutPath> </sparseCheckoutPaths> </hudson.plugins.git.extensions.impl.SparseCheckoutPaths> <hudson.plugins.git.extensions.impl.CleanBeforeCheckout/> <hudson.plugins.git.extensions.impl.PathRestriction> <includedRegions>^CM/build_name/.* ^DotNet/Common/.* ^DotNet/One/.* ^DotNet/Two/.* ^DotNet/StrongNameKey.snk</includedRegions> <excludedRegions></excludedRegions> </hudson.plugins.git.extensions.impl.PathRestriction> <hudson.plugins.git.extensions.impl.DisableRemotePoll/> </extensions> </scm> <triggers> <hudson.triggers.SCMTrigger> <spec>H 7-21/1 * * *</spec> <ignorePostCommitHooks>false</ignorePostCommitHooks> </hudson.triggers.SCMTrigger> </triggers>
Since it is the same behavior whether you downgrade or not, then it is probably not an instance of the bug I've been trying to isolate. The bug I'm trying to isolate first appeared in the transition from 2.3.4 to 2.3.5. You may need to debug the plugin to identify why it is building continually.
If you can't do that, it would be a great help if you can provide a repeatable set of steps so that I can construct a job which has the same behavior, without requiring that I install and configure a Gerrit server. I can't promise to investigate it (plugin maintenance is done on my personal time), but I'm much more motivated to help when a bug is submitted with detailed steps which can reconstruct the failure case.
I can try to debug it myself. If I run into problems w/ that I will try to replicate with a test repo on github and post steps here.
The bug that appeared in the transition from 2.3.4 to 2.3.5 is now resolved in git plugin 2.4.0 (which requires git client plugin 1.18.0). You may want to try 2.4.0 (with 1.18.0) to see if your problem is resolved as a side effect of the fixes in 2.4.0.
Resolved due to no feedback on the "is it fixed in 2.4.0" question in 2 months
When polling a GitHub project (which is outside of the system that hosts jenkins), polling correctly identifies that no changes have been found.
GitHub project: https://github.com/jenkinsci/jenkins.git
This does not seem to matter if a github credential is supplied or if the project is polled anonymously.