Queue a Build

After you define your build processes by creating one or more build definitions, you can start to reap the benefits of your build system. Most build processes are defined with automatic triggers. Whether your build definition has a manual or automatic trigger, you can manually queue a build whenever necessary.

Public Builds

Regardless of whether an automatic trigger is specified in a build definition, you can manually queue the build.

Required Permissions

To follow this procedure, your Queue builds permission must be set to Allow. For more information, see Team Foundation Server Permissions.

To queue a public build from Visual Studio

1. In Team Explorer:

   1. If you are not already connected to the team project that you want to work in, then connect to the team project.

   2. Choose Home, and then choose Builds.

   3. On the Builds page, under Favorite Build Definitions or All Build Definitions, open the shortcut menu for a build definition, and then choose Queue New Build.

   The Queue BuildTeamProjectName dialog box appears.

2. In the Build definition list, the build definition is selected and its description is displayed below. If you want to queue a different build definition, you can select one from the list.

3. In the What do you want to build? list, leave Latest sources selected.

4. (Optional) In the Build controller list, select a build controller other than the default build controller.

5. (Optional) In the Priority in queue list, select one of the following values: High, Above Normal, Normal, Below Normal, or Low.

   The Position box displays the build's estimated position in the queue.

6. (Optional) The Drop folder for this build box displays the location where outputs such as binaries and log files are stored when the build is completed. If you want to store the outputs in a different location, type the path to that location in this box.

   Important

   If you modify this value, you must specify a folder that has been prepared for use as a drop folder. You cannot modify this value if you have specified Copy build output to the server as the staging location for the build definition.

   See Set Up Drop Folders.

7. (Optional) On the Parameters tab, view and override other build definition settings for this run only.

   If the build definition is based on either the Default Template or the Upgrade Template, see Define a Build Process that is Based on the Default Template or Use Legacy Build Processes for more information about these parameters.

8. Choose Queue.

Private Builds

You queue a private build if you want to build the changes that you have put into a shelveset. You can use a private build (also known as a "buddy build") to validate changes to your code before you check it in. By performing a private build of your changes before you check them in, you can reduce the chance that they will break any builds that your team runs regularly, such as the nightly build.

How Private Builds Differ from Public Builds

The results of a completed private build differ from a completed public build in the following ways:

• A private build resembles a gated check-in build in that you are building code that includes changes in a shelveset. However, your changes are not automatically checked in for you after a private build as they are after a gated check-in build.

• The following build process parameters are presumed to be False and therefore have no effect, regardless of the setting specified in the build definition:

  • Label Sources

  • Create Work Item on Failure

  • Associate Changesets and Work Items

• In Build Explorer, the completed build appears next to the following icon:

• The completed build is named by using the format Build N where N is a unique integer value. This format differs from that of public builds, which you specify by using the Build Number Format parameter.

• For each build definition, you specify a separate (and optionally different) retention policy to limit the number of completed private builds that are stored in the system.

Queue a Private Build

Required Permissions

To follow this procedure, your Queue builds permission must be set to Allow. For more information, see Team Foundation Server Permissions.

To queue a private build from Visual Studio

1. In Team Explorer:

   1. If you are not already connected to the team project that you want to work in, then connect to the team project.

   2. Choose Home, and then choose Builds.

   3. On the Builds page, under Favorite Build Definitions or All Build Definitions, open the shortcut menu for a build definition, and then choose Queue New Build.

   The Queue BuildTeamProjectName dialog box appears.

2. In the Build definition list, the build definition is selected and its description is displayed below. If you want to queue a different build definition, you can select one from the list.

3. In the What do you want to build? list, select Latest sources with shelveset.

   The Shelveset name box appears.

4. Follow one of these steps:

   • If you already have a shelveset, type its name into the Shelveset name box, or choose the ellipsis (…) button to search for the shelveset.

   • If you want to put some pending changes from your workspace into a shelveset and then build those changes, choose Create.

5. (Optional) If you want to check in the changes in the shelveset if the build is successful, select the Check in changes after successful build check box.

   Important

   If you select this check box, the build is run as a gated check-in build instead of as a private build. For more information about gated check-in builds, see Define a Gated Check-In Build Process to Validate Changes.

6. (Optional) In the Build controller list, select a build controller other than the default build controller.

7. (Optional) In the Priority in queue list, select one of the following values: High, Above Normal, Normal, Below Normal, or Low.

   The Position box displays the build's estimated position in the queue.

8. (Optional) Follow these steps to specify the folder where the outputs, such as binaries, of the build will be downloaded:

   Note

   Ignore the Drop folder for this build box because it has no effect in a private build.

   1. Choose the Parameters tab, and then expand the Advanced group.

   2. In the Private Drop Location box, type the UNC path to the folder where you want to store the outputs when the build is completed.

      Note

      • If you do not specify this folder, the build will not fail, but a warning will appear in the build log.

      • If you modify this value, you must specify a folder that has been prepared for use as a drop folder. For more information, see Set Up Drop Folders.

9. (Optional) On the Parameters tab, view and override other build definition settings for this run only.

   If the build definition is based on either the Default Template or the Upgrade Template, see Define a Build Process that is Based on the Default Template or Use Legacy Build Processes for more information about these parameters.

10. Choose Queue.

Retry a completed build

When you are testing some potential changes to a build process or experimenting with options, you can quickly queue a public or private build using the same options you specified when you queued build that is now completed.

To retry a completed build from the Builds page

• In Team Explorer:

  1. If you are not already connected to the team project that you want to work in, then connect to the team project.

  2. Choose Home, and then choose Builds.

  3. On the Builds page, under My Builds, open the shortcut menu for a completed build, and then choose Retry Build.