Hi,
we have been having issues with continua missing commits for a while now but have not been able to reliably reproduce it until now.
We now noticed that sometimes the commits in our git repository have time stamps that are not in the same chronological order as the commits were made. This happens a lot when two developers have a slightly different system time but make a commit to the same branch.
For clarification I have this git log from a test repository with which I have been able to reproduce the behaviour reliably.
commit 0d84b99180ae38718f899e2040e18545a6b8819f
Author: Test2 test2@test.test
Date: Tue Feb 3 08:19:38 2015 +0100
This commit was made after the previous one but with an earlier time stamp
commit 05e7c3b3aa339da3d7610ec7ef17eec3c5022d45
Author: Test test@test.test
Date: Tue Feb 3 08:39:06 2015 +0100
Test commit from the future/test@test.test/test2@test.test
Commit 05e7c3b was the latest one known to Continua before the next commit was made. As you can see from the log the next commit has an earlier time stamp than the previous one. Continua will now keep working with commit 05e7c3b and never detect that another commit was made in the repository. The only way around this is to either reset the repository or make another commit with a later time stamp so that Continua can detect it.
Regards,
Christoph
I am not sure if this has always been the same behaviour but we have seen similiar effects from Continua 1.0.0.0 until 1.5.1.93.
Hi Christoph,
I’ll need to do some further testing on this. We currently run git fetch to get a range of new commit hashs for each branch and then use git log to get the list of changeset in these hash ranges. We don’t use dates here so I’m not sure why this would miss commits even if they have mixed up commit dates.
Are the changesets actually missing from Changes tab on the Configuration view or is the problem only that they are not triggering builds?
Can you post details of your trigger? Do you have a quiet period set? Are you associating all changesets since last build or the latest changeset?
Can you also run “git log --format=fuller --topo-order --reverse” and post the output for those two commits? This will show us the difference between the commit date and the author date.
The commits do not show up in the Changes tab when starting builds manually and they don’t trigger automatic builds either.
We have set up a repository trigger with a quiet period of 10 minutes. It was set up to associate only the latest changes but it does not work when changing that to “All since last successful build” either. We have also checked the “Force repository check” option.
Here is the git log:
commit 05e7c3b3aa339da3d7610ec7ef17eec3c5022d45
Author: Test test@test.test
AuthorDate: Tue Feb 3 08:39:06 2015 +0100
Commit: Test test@test.test
CommitDate: Tue Feb 3 08:39:06 2015 +0100
Test commit from the future
commit 0d84b99180ae38718f899e2040e18545a6b8819f
Author: Test2 test2@test.test
AuthorDate: Tue Feb 3 08:19:38 2015 +0100
Commit: Test2 test2@test.test
CommitDate: Tue Feb 3 08:19:38 2015 +0100
This commit was made after the previous one but with an earlier time stamp/test2@test.test/test2@test.test/test@test.test/test@test.test
Hope this helps.
Hi Christoph,
Is that the Changes tab on the Configuration view e.g. http://localhost/ProjectName/ci/configurations/changes/ConfigurationName or the Build view?
In my tests the changeset appears in the Configuration Changes list, but when I start a build manually it only takes the commit with the latest date.
With the trigger: if a commit with an earlier date comes in while a trigger is in a quiet period, it gets added to the trigger, however the one with the latest date gets built.
We currently use the date to pick the latest commit as this works across all repository types. We can probably change this by constructing a new sort field based on the topological order of the commits.
Sorry, I only checked the changes in the Build view.
The configuration view does show all the commits correctly.