One of the developers noticed that builds were not getting new changes from a GIT repo since she deleted a commit from git via rebase.
I believe that's the reason we're getting this error:
Build Error Error updating cache for repository TWUI_Dev to changeset revision 383fda543fb9a0da04650917e28c381db541fc51. Details: Error occurred while updating repository cache to changeset 383fda543fb9a0da04650917e28c381db541fc51 : Running 'C:\Program Files\Git\cmd\git.exe' with arguments "checkout --force 383fda543fb9a0da04650917e28c381db541fc51" failed with return code 128 and error output: "fatal: reference is not a tree: 383fda543fb9a0da04650917e28c381db541fc51 "
I've tried resetting the repo. Also deleted local repo cache and reset. Neither of those helped. I've also run cleanup with 0/0 so it deletes all old logs (we didn't need them) just in case some old build was triggering a pull from the deleted changeset. None of these things helped.
What I ended up doing is queuing the configuration with 'all changes since last successful build' selected. I don't know for sure that it worked, I'm stuck behind a few other huge builds at this point. However previous attempts never got to the queued/waiting for agent point.
This is with CI 1.8.1.598
I also noticed that with the cleanup policy set to 0 min and 0 max, some really old build from 17 weeks ago has reappeared.
IMO deleting commits is a bad thing, no clue why anyone would do this.. However it happened.. and for all I know it may have nothing to do with the problem, just a theory at this point.
I managed to build once, then this problem is back. I’m resetting the repo (with delete cached changesets) option and will retry.
Hi b.walker,
We’re doing some testing to see if we can reproduce this error and handle it appropriately. We’ve tried deleting commits using git rebase -i but have not seen the error yet? Can you give us some more information about commit 383fda543fb9a0da04650917e28c381db541fc51 so we can narrow down our testing? Is this the commit that was deleted? Otherwise is it on the same branch at the commit that was deleted. Was the commit deleted from the head of a branch? Are there any other commits of the branch? What output do you get when running ‘git log 383fda54’?
If the error is still occurring then please enable debug logging, restart the Continua CI Server service, then send the debug log to support@finalbuilder.com after once the error reoccurs.
I think this may be related to the ‘Associate’ option. ‘Most recent changesets’ seem to trigger this error, and once that happens subsequent builds fail with the same error. If I cleanup all old builds (set to keep 0min/0max) then run with “All changesets since last successful build” option it works at least once… I’ve got a second build waiting now.
Hopefully this is a known/fixed bug or the like, I’m waiting to hear back from other devs on updating CI on this server…
As far as I know the delete happened on a the head of the same branch we’re have configured in CI for the repository (not master).
E:\Continua\Rc\1f699b23>git log 383fda54
fatal: ambiguous argument ‘383fda54’: unknown revision or path not in the workin
g tree.
Use ‘–’ to separate paths from revisions, like this:
‘git […] – […]’
If I run git log with full changeset:
E:\Continua\Rc\1f699b23>git log 383fda543fb9a0da04650917e28c381db541fc51
fatal: bad object 383fda543fb9a0da04650917e28c381db541fc51
I think that means it’s been deleted? GIT isn’t my usual VCS… however I’ve got a command prompt in the servers local repository do I can run any git commands that might help.
Also, this git repository is hosted on bitbucket if that makes any difference. I have no clue what version of git they have currently… and we’ve had weird problems before… although nothing that wasn’t easily fixable.
I have another build in progress, we may be out of the woods on this although I haven’t tried ‘quick queuing’ a build yet which seemed to trigger this problem last time. We have a nightly builds scheduled, and so far I haven’t heard back on updating CI so I’m going to leave this as is for the rest of the evening.
I’ll check back in the morning… thanks for looking into this!
It’s not a known bug, but we should be able to create a fix once we can reproduce or see what is happening in the debug log.
Are you resetting the repository after cleaning up all the builds? It would help if the reset could be included in the debug log so we could see how the missing changeset id is getting back into the database. Or maybe its not being deleted - are there any other errors on the Event Log page?
Is there a way to export the server event logs? We have nobody following up on these, there are a lot of events. I think the relevant entries are just the same message I noted above with git error.
I was able to enabled debug logging, but only for a short time as this is a production server. I should be able to complete more thorough tests later this evening. Here’s what I did this morning:
9:33AM - Enabled debug logging and restarted CI server 9:33am
9:34AM - Kicked off build that should fail (did last night)
9:43AM (roughly - build failed.
9:43AM - Changed cleanup policy of “SVN Trunk - GIT dev” configuration to keep 0 logs. NOTE: build #352 from 17 weeks ago stuck, not deleting… I suspect that might be related to this issue? The build is not pinned, I have no idea why it would not clean up. Even with our usual policy it should have been gone a long time ago.
9:47AM - Turned off debugging.
I don’t see a way to attach files here, I emailed the debug log and diagnostic report to support@finalbuilder.com subject “ATTN: Dave Sparks - debug information related to forum post” It’ll be coming from my work email @drbsystems.com. Hope that’s a good way to get it to you.
I have the system in an state where I can duplicate success and failures. I can run a single build after running cleanup with keep 0 min and 0 max (the #352 build never gets deleted). After I get a good build, subsequent builds fail prior to queuing with the above git error.
If I run cleanup again, I can build one build. Then failure. Seems I can duplicate this consistently.
Hopefully that bit is helpful.
Thank you for sending the debug log and diagnostics log. We have now uploaded a new version 1.8.1.664 which ensures that any deleted changesets remaining in the database after a repository reset (because they are linked to an existing build) are not taken as the latest changeset and used for the new build.
After installing this version, the offending changeset will still be selected on the first build you run, but will no longer be selected on subsequent builds. Adding a new changeset to the dev branch in your repository or resetting the repository will also reorder the changesets, so that the next build will select the correct latest changeset.
Running a configuration cleanup should also remove your old build. Let us know if it doesn’t.
Thanks! I’ll install this weekend, and let report back on this thread.
We’re back in business. I did the following:
* upgrade to 1.8.1.664
* started build that was previously failing - errored out
* started the same failing build a second time, this time it worked fine. Old build log from 17 weeks ago still in the list
* manually ran cleanup, old build removed.
* Did another build just in case, no issues.
Thanks again, as far as I can tell this is resolved with the patch.
Thanks for confirming the fix worked.