This project is read-only.
The configuration tab is where you setup what TfsBuildLab should do (it's pretty straight forward), as you can see in the screenshot below the tab is split into three parts. The left pane is the navigation of team projects and their build types (the resouces you can configure). The right pane is the data pane and split in a upper half (representing the retention policies) and the lower half (representing the triggers). If you double click on an existing row you will be able to edit it.

You can quickly setup a new build type by copy an existing configuration. To do this you right click on a build type in the tree view and you will be presented with an option called copy on the context menu, this will bring up a dialog prompting you for which team project and build type you wish to copy the configuration to.

Adding a retention policy
Adding a scheduled build
Adding a continous integration build

admin_tab_configuration.jpg

How does a retention policy work?

  1. Execute each registered retention policy
    1. List all available builds
    2. Sort the list of builds
    3. Enforce the policy type Builds (the maximum number of builds for a specific build type and build result to be allowed)
      1. Start deleting builds in reverse order (starting with the oldest) and stop when the number of builds no longer is exceding the configured value.
    4. Enforce the policy type Days (the maximum days worth of builds for a specific build type and build result to be allowed)
      1. Start deleting builds reverse order (starting with the oldest) and stop when the startedtime in nolong older than now + the configured value.
  2. Wait for the configured ammount of time specified in the setting RetentionPolicyEnforcementInterval (see installation for more info)

How does a scheduled build work?

  1. Look for any triggers of the type Schedule
    1. Schedules where found
      1. Determine next one that has not yet occurred (if none is available we take the lowest and schedule for the next day)
      2. Put the thread in a wait state until the next scheduled time occurs
    2. The thread wakes up on the apointed time and processes all build types (there can be more than one build type configured to execute at the same time) configured for execution by posting them on the build queue.
  2. No Schedules found wait for the configured ammount of time specified in the setting ScheduleManagementInterval (see installation for more info)
(Note: Currently if the thread has been put in a wait state by a schedule and you add a new schedule that would occur before the service is activated again this schedule will not happen until the next day unless the service is restarted, This will probably change in a later version).

How does a continous integration build work?

Dealing with checkin events

  1. List all the affected build types based on a matching of the workspace mappings and the contents of the changeset
  2. Sort out the ones that has triggers matching the contents of the changeset
  3. Put a build request for the build types left on the queue
    1. Check if there already exsist a request for that build type (that was triggered by a CI build) if not we create a new build request

Dealing with build events

  1. Determine if the build completed was triggered by TfsBuildLab and is registered as a CI build (CheckinInclude trigger)
  2. If build failed
    1. Trigger sending of emails
      1. Get a list of all changesets that where involved in the build (since there can potentionally be many checkins between the time we requested the build and the time it actually executed we need to resolve this)
        1. For each changeset in the list try to resolve the username and email using LDAP query specified in the setting CINotificationResolvementLDAPPath (see installation for more info).
        2. Construct email and send it to the involved parties (the owners of the changesets)
        3. If the setting CIAdministrativeNotificationEmail is used a mail will be sent to the addresses specified there.
    2. Trigger creation of work item (similar to that already in the team build process)

How does queue manangement work?

  1. Peek the next build request in the queue
    1. Try to start the build on the default build server (that is the one specified in the TFSBuild.proj)
      1. If a failure occured bump up the delivery attempt counter (we only try three times to deal with bad requests) push the cursor forward in the queue and start over
      2. If a build is already in progress push the cursor forward in the queue and start over
    2. The build started ok, register for notification to handle continous integration issues
    3. Pop the build request from the queue and start over
  2. When no more build request exsists in the queue wait for the configured ammount of time specified in the setting QueueManagementInterval (see installation for more info)

Last edited Aug 26, 2007 at 8:31 PM by PeterBlomqvist, version 13

Comments

No comments yet.