3

When the source control repository is unreachable cruise control keeps going back to check for modifications. While the latest build was successful the dashboard reports failure but cctray reports success.

Is there some way I can catch this scenario and have these two agree?

Cœur
  • 37,241
  • 25
  • 195
  • 267
foo
  • 1,495
  • 2
  • 11
  • 15

2 Answers2

1

Yes this scenario can occur when the CCTray hangs on the local PC. If the issue is occuring at the dashboard then it means the IIS Server hangs where the CruiseControl server is running.

To resolve this is to identify where the issue is at. If the issue is at the CCTray level then restart the CCTray. If the issue is at the Dashboard level then restarting the IIS should fix it.

otaku
  • 964
  • 5
  • 16
1

This is actually due to an issue in CruiseControl; not CCTray itself.

If source control fails (say because of a timeout or connection failure) the following will be true:

  1. CruiseControl will set project state to Exception as the project is currently in an error state
  2. CruiseControl will NOT modify the last build status, as a build has not occurred
    • so if the previous build succeeded - the project will report Success for the last build status

CruiseControl only reports - natively - the last build status via the API that CCTray uses. Getting it to inspect the project status is more complicated and ends up being less efficient. As such the CCTray reports the 'status' as the last build status rather than a hybrid of the two.

The WebDashboard shows the project status and the last build status hence true status of the project is better evaluated.

This issue has several other side-effects; such as projectTriggers firing in this circumstance; as these also do not check the project status.

Ideally CCTray - and projectTriggers, et. al - would check both the project status and last build status and report the outcome as a combination of both.

Simon Laing
  • 1,194
  • 7
  • 18