Queue a Build

  • Article

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. For more information, see Specify Build Triggers and Reasons.

Whether your build definition has a manual or automatic trigger, you can manually queue a build whenever necessary.

Common tasks

Supporting content

Queue a public build if you want to build the most recent version of the source code in the version control server.

To queue a public build at a command prompt, use the TFSBuild start command.

Queue a private build if you want to build 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.

To queue a private build at a command prompt, use the TFSBuild start command with the /shelveset option.

Public Builds

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

Required Permissions

To perform 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, click the appropriate team project.

  2. On the Build menu, click Queue New Build.

    The Queue Build TeamProjectName dialog box appears.

  3. In the Build definition list, select a build definition.

    If the build definition that you selected has a description, it appears under the Build definition list.

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

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

  6. (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.

  7. (Optional) The Drop folder for this build box displays the folder where outputs such as binaries are stored when the build is completed. If you want to store the outputs in a different location, type the Universal Naming Convention (UNC) 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. For more information, see Set Up Drop Folders.

  8. (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 Workflow Builds Using the Default Template or Use Legacy MSBuild Builds Using the Upgrade Template for more information about these parameters.

  9. Click Queue.

    Build Explorer appears with the Queued tab displayed. For more information, see Manage and View Completed Builds.

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: ms181722.Icon_BldPrivateBuild(en-us,VS.100).gif

  • 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 perform 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, click the appropriate team project.

  2. On the Build menu, click Queue New Build.

    The Queue Build TeamProjectName dialog box appears.

  3. In the Build definition list, select a build definition.

    If the build definition that you selected has a description, it appears under the Build definition list.

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

    The Shelveset name box appears.

  5. Perform one of the following steps:

    • If you already have a shelveset, type its name into the Shelveset name box, or click 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, click Create.

  6. (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.

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

  8. (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.

  9. (Optional) Perform the following 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. Click 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.

  10. (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 Workflow Builds Using the Default Template or Use Legacy MSBuild Builds Using the Upgrade Template for more information about these parameters.

  11. Click Queue.

    Build Explorer appears with the Queued tab displayed. For more information, see Manage and View Completed Builds.

See Also

Tasks

Create a Basic Build Definition

Concepts

Define a Build Using the Default Template

Working with Shelvesets

Define a Gated Check-In Build Process to Validate Changes