Build options

Note

In Microsoft Team Foundation Server (TFS) 2018 and previous versions, build and release pipelines are called definitions, runs are called builds, service connections are called service endpoints, stages are called environments, and jobs are called phases.

Create a work item on failure

If the build pipeline fails, you can automatically create a work item to track getting the problem fixed. You can specify the work item type.

You can also select if you want to assign the work item to the requestor. For example, if this is a CI build, and a team member checks in some code that breaks the build, then the work item is assigned to that person.

Additional Fields: You can set the value of work item fields. For example:

Field Value
System.Title Build $(Build.BuildNumber) failed
System.Reason Build failure

Q: What other work item fields can I set? A: Work item field index

Allow scripts to access the OAuth token

Select this check box if you want to enable your script to use the build pipeline OAuth token.

For an example, see Use a script to customize your build pipeline.

Default agent pool

TFS 2017.1 and older

This section is available under General tab.

Select the pool that's attached to the pool that contains the agents you want to run this pipeline.

Tip

If your code is in Azure Pipelines and you run your builds on Windows, in many cases the simplest option is to use the Hosted pool.

Build job authorization scope

TFS 2017.1 and older

This section is available under General tab.

Specify the authorization scope for a build job. Select:

  • Project Collection if the build needs access to multiple projects.
  • Current Project if you want to restrict this build to have access only the resources in the current project.

Scoped build identities

Azure DevOps uses two built-in identities to execute pipelines.

  • A collection-scoped identity, which has access to all projects in the collection (or organization for Azure DevOps Services)
  • A project-scoped identity, which has access to a single project

These identities are allocated permissions necessary to perform build/release execution time activities when calling back to the Azure DevOps system. There are built-in default permissions, and you may also manage your own permissions as needed.

The collection-scoped identity name has the following format:

  • Project Collection Build Service ({OrgName})
  • For example, if the organization name is fabrikam-tailspin, this account has the name Project Collection Build Service (fabrikam-tailspin).

The project-scoped identity name has the following format:

  • {Project Name} Build Service ({Org Name})
  • For example, if the organization name is fabrikam-tailspin and the project name is SpaceGameWeb, this account has the name SpaceGameWeb Build Service (fabrikam-tailspin).

By default, the collection-scoped identity is used, unless the Limit job authorization scope to current project is set in Project Settings > Settings.

Limit job authorization scope

Limit job authorization scope to current project can also be set at the organization level in Organization Settings. When Limit job authorization scope to current project is set in Organization Settings, it is grayed out and can't be set in Project Settings.

Limit job authorization scope disabled

Managing Permissions

One result for setting project-scoped access may be that the project-scoped identity may not have permissions to a resource that the collection-scoped one did have.

A solution is to assign permissions directly to the project-scoped identity, if required. These can be assigned cross-project within the same project collection.

Note

If you don't see the project-scoped identities, you must first enable Limit job authorization scope to current project and then run a pipeline in that project.

Configure permissions to access another repo in the same project project collection

In this example, the fabrikam-tailspin/SpaceGameWeb project-scoped build identity is granted permission to access the FabrikamFiber repository in the fabrikam-tailspin/FabrikamFiber project.

  1. In the FabrikamFiber project, navigate to Project settings, Repositories, FabrikamFiber.

    Repository access

  2. Choose the + icon, start to type in the name SpaceGameWeb, and select the SpaceGameWeb Build Service account.

    Add user

  3. Configure the desired permissions for that user.

    Set permissions

Configure permissions to access other resources in the same project collection

In this example, the fabrikam-tailspin/SpaceGameWeb project-scoped build identity is granted permissions to access other resources in the fabrikam-tailspin/FabrikamFiber project.

  1. In the FabrikamFiber project, navigate to Project settings, Permissions.

    Project settings

  2. Choose Users, start to type in the name SpaceGameWeb, and select the SpaceGameWeb Build Service account. If you don't see any search results initially, select Expand search.

    Add user

  3. Configure the desired permissions for that user.

    Set permissions

Build (run) number

This documentation has moved to Build (run) number.