History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: CIB-1874
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: 3 3
Assignee: jason
Reporter: Rohan McGovern
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Pulse

Polling git scm fails after changing git repository

Created: 03/Mar/09 02:24 AM   Updated: 02/Jul/09 09:47 AM
Component/s: None
Affects Version/s: 2.0.19
Fix Version/s: 2.1.4, 2.0.33

Original Estimate: Unknown Remaining Estimate: Unknown Time Spent: Unknown


 Description  « Hide
I had a rule set up in Clean Update mode pointing at a particular git repo and branch. It did some builds against that repo and branch.

Then I changed the repo and branch it pointed to, and the server stopped seeing new changes. These messages were in the log:

03/03/2009 10:05:28: Polling SCM for changes...
03/03/2009 10:05:29: Error polling SCM: Git command: git log --name-status --pretty=format:%H%n%cn%n%cd%n%s%n. --reverse a1dd87faaaf3420b4f4c506c643ebbf8d6f3fa5b..HEAD exited with non zero exit code: 128.
03/03/2009 10:11:26: Polling SCM for changes...
03/03/2009 10:11:28: Error polling SCM: Git command: git log --name-status --pretty=format:%H%n%cn%n%cd%n%s%n. --reverse a1dd87faaaf3420b4f4c506c643ebbf8d6f3fa5b..HEAD exited with non zero exit code: 128.

I think the problem is that a1dd87faaaf3420b4f4c506c643ebbf8d6f3fa5b is a commit in the old repo and not the new repo, therefore the command fails.

The problem persisted even after doing a reinitialization.

Currently I'm about to attempt the workaround of temporarily setting the project to Clean Checkout, letting it do one build in that mode, then setting it back to Clean Update (which is unfortunate because a full checkout takes hours).

 All   Comments   Work Log   Change History      Sort Order:
Daniel Ostermeier - 03/Mar/09 02:30 AM
Hi Rohan,

OK, let me know how you go, although if the problem is with the commit id, then I suspect a clean checkout will not fix it. The scm polling process keeps track of the last commit id so that it can check for changes since then. The project re-init process does not clear that, and a clean checkout will not clean that either. That information is actually stored in memory, so a server reboot should fix that temporarily.

Please let me know how you go.

Rohan McGovern - 03/Mar/09 02:36 AM
The workaround makes no difference, it might be necessary to delete and recreate the project.

Daniel Ostermeier - 03/Mar/09 03:21 AM
Thanks for the update. I will need to run some more tests locally to find out what is going wrong.

Cheers,
-Daniel

Daniel Ostermeier - 03/Mar/09 03:42 AM
Just to clarify, the workaround that didn't work was restarting Pulse?

Cheers,
-Daniel

Rohan McGovern - 03/Mar/09 05:32 AM
No, it is the Clean Checkout workaround which didn't work. Sorry, I hadn't read your first comment when I posted mine. Restarting the Pulse server isn't really an option.

Rohan McGovern - 04/May/09 02:03 AM
On a separate Pulse installation, I can confirm that restarting the server fixes the problem... the logs say "Retrieved initial revision:", with a SHA1 from the new repo.

Rohan McGovern - 30/Jun/09 01:23 AM
This bug can also appear without changing the SCM config at all if the git repo is rebased. Basically, if anything happens such that, after a `git pull', there is no longer a path from the last known SHA1 to HEAD, Pulse won't see any new changes until the server is restarted. This makes some git workflows impractical to use with Pulse.

jason - 30/Jun/09 06:27 AM
Hi Rohan,

Thanks for the update. We certainly need to be clearing our internal "latest revision" cache when a project is reinitialised, which will remove the need for a restart.

jason - 01/Jul/09 07:04 AM
Fixed in change 6080. Note that this change just clears the latest revision cache on a project reinitialisation (which happens when you edit the SCM config). It does not handle things like rebasing, but the proposed fix for CIB-2024 combined with this fix will.

jason - 02/Jul/09 09:47 AM
Merged to trunk in change 6087.