We have a configuration we start only manually. We noticed now, that when we do this, right after (some seconds) something has been committed, the new changesets do not get noticed now.
When we start a second build, the changesets are present.
Before we switched to manual start, we had a commit trigger where the option “force repository check” can be enabled. so we never had this problem here.
So i assume, that this option “is missing” when starting a build manually. This is really bad, because someone would start this configuration by thinking all committed changes are associated.
Additionally, we set also “All changesets since last successful build” when we started the build, so it means that something else is going wrong here.
Hi Christian,
Thanks for reporting this. We had a similar report a couple of days ago and found there was a timing issue between storing the new changeset and continuing the build. We have now implemented a fix in the latest versions of both 1.5 and 1.6 relase candidate.
Great, thanks
I am still seeing apparently the same symptoms in 1.6.0.132. I want to manually trigger builds, but when I do so the latest commits are not being picked up from the repos. Is the expected behaviour that the server should check the repos and pull any changes before starting the build? That’s not what I am seeing… Its not entirely consistent and seems to be worse for large commits, so it could still be a timing issue perhaps.
Which repository type are you using?
Git via the BitBucket-Default connector.
This is still happening in 1.6.0.279. When I trigger a build manually, the repositories are checked and the changes for the configuration are updated, but these new changes are not included in the triggered build. Workaround is still to poll the repos manually, wait, then trigger the build.
Woops, think this is actually a problem on my end…apologies!