Changesets sometimes are not firing Builds

#1

We have observed many Changesets are not firing Builds by Repository Triggers, but we can’t make the problem reproducible.

For example:

A commit is sent to a Pull Request, and no build is triggered. Then the same user, hours later, makes a new “fake” commit by changing only one blank line in the same file, so the build is triggered.

This leads me to conclude that there is no misconfiguration, but there is something else preventing the trigger from triggering the build. We have tried to enable logging on Continua.Server.Service.exe.config but we have not found any information that would lead to the problem mentioned.

How could I find out why many Changesets aren’t firing Builds by Triggers?

Follows print of a recent example. No associated builds for this changeset:

image
image.png768×503 14.5 KB

In the Changes tab, the changeset only appears on page 9 although it was one of the most recent:

image
image.png1720×919 61.8 KB

Trigger that should have fired, Files configuration:

image
image.png644×567 21.6 KB

Making a fake commit, same files, the Build was fired by Repository Trigger:

image
image.png1626×363 18.9 KB

#2

Hi Rafael,

Are there any relevant errors on the Event Log page in the Administration section?

Otherwise, we would need to see a debug log (and the rest of your trigger settings) to understand what is happening here.

If debug logging was enabled when the changeset was committed and detected, then send a copy of the debug log to support @ finalbuilder.com (or to me on this forum via a direct private message). If not, then enable debug logging and wait until the issue occurs again before sending the log.

There are many log messages in the relevant area of code, so this should allow us to diagnose the issue.

#3

We have sometimes seen this warning in event logs, but the timestamp does not match the problem that occurred:

event-b2dbb0ef.txt (2.9 KB)

Meanwhile, I will re-enable the debug log and monitor the next time the problem occurred.

#4

As per our conversation via direct message, this issue appears to be due to a timeout when saving list of changeset files to database. We have now batched, the adding of changeset files to the database to avoid this error, and improved error handling with retries. See v1.9.1.538.