Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 324976

Summary: Changed source in Git commits not being picked up
Product: Community Reporter: Steve Powell <zteve.powell>
Component: CI-JenkinsAssignee: Eclipse Webmaster <webmaster>
Status: CLOSED FIXED QA Contact:
Severity: major    
Priority: P3 CC: glyn.normington
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Mac OS X - Carbon (unsup.)   
Whiteboard:

Description Steve Powell CLA 2010-09-10 10:42:47 EDT 
Made change to virgo.test.snapshot underlying git repo (updated build-test-framework/build.xml) and pushed.  Git commit id nnnnn.

Ran job

Job log shows that the commit id nnnnn is correctly fetched.

Build job, however, does not get this file -- checked Workspace after job failed, and build-test-framework/build.xml is OLD level NOT new level.

Job is: https://hudson.eclipse.org/hudson/me/my-views/view/Virgo/job/virgo.test.snapshot/201/
Comment 1 Steve Powell CLA 2010-09-10 11:04:06 EDT 
Deleted workspace -- results were peculiar (!) repo seemed to be badly constructed.

We then removed options from git checkout settings in job (removed name of repo to use default -- this turns out to be 'origin' -- is this 'name of remote' instead of 'name of repo' a misprint??).  Also removed directory (optional) name to use default (which is probably org.eclipse.virgo.test -- but I cannot tell).

Then re-ran job and apparently we get the correct source.

This was therefore probably caused by unannounced changes to usage of job configuration settings.

If you can confirm this we can close this bug.
Comment 2 Steve Powell CLA 2010-09-17 11:47:00 EDT 
git repo polling for all virgo.* job configurations are not triggering jobs -- polling logs indicate that changes are not being detected. Manual jobs do not see updates that occurred days before.

There is something wrong with the way the git repositories are being polled/downloaded.

This has not worked correctly since we moved to the new (stable) hudson environment.  Was working fine on the old one -- can it be something to do with proxys?   :-)
 
This affects our strategic use of hudson for a ci-build environment.
Comment 3 Steve Powell CLA 2010-09-21 05:16:02 EDT 
Problem identified.  The 'branch to build' default (in git section of job configuration) was reset at the same time that the name of the repo (remote?) was reset to default. The new default fields are not displayed until the config is closed and re-opened.

The branch to build default was (incorrectly) generated from the old value of the name of the repo(remote) -- thus the git polling and git fetch statements were not fetching the correct remote node branch.  Ergo -- no changes found.  

[Actually no remote found ERROR would have been more helpful, but I guess you can't expect good diagnostics.....]

Another trawl through the settings for all our jobs is required, but we can now fix this.

Thank you for your support.
Comment 4 Steve Powell CLA 2010-10-21 12:38:16 EDT 
Now an old config problem -- resolved.