Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Repository check-in occurs. Specified by the Repository Trigger
  2. A configuration completes. Specified by the Project Completion Build Completed Trigger
  3. It's a certain time of the day/week/month. Specified by the various Time Triggers

Each of these trigger types have their own fields and values to be set, the explanation of each field is described in their respective pages of this wiki. Regardless of the trigger type selected, they all share a set of common fields which are described below.

Image RemovedImage Added

Build Priority

...

When the trigger is executed and the Configuration is queued, the build needs to decided what to do with the Repositories attached to the Configuration. In the case of a Repository Trigger, the triggering Repository is assumed to be in a working state since it just triggered the build. However, the same can't be said for all non-triggering repositories of which there could be many. In the case of Time Triggers and the Project Completion Build Completed Trigger, all repositories are non-triggering repositories. For Repository Trigger, the non-triggering repositories are all those repositories other than the one that triggered the build. When the force repository check option is set, all non-triggering repositories are check to see if they're in an error state. If they're in an error state, an attempt will be made to fix them. If they're still in an error state then the build won't start and you'll see an entry in the Event Log with the details.

...