Compilar repositórios do TFVC

Azure DevOps Services | Servidor Azure DevOps | Azure DevOps Server 2022 | Azure DevOps Server 2020

Escolha o repositório a ser compilado

Ao editar um pipeline que usa um repositório TFVC, você tem as seguintes opções.

• Limpo
• Especificar caminho local
• Fontes de rótulo

Nome do repositório

Nome do repositório TFVC.

Mapeamentos (workspace)

Inclua com um valor de tipo de Map apenas as pastas necessárias para o pipeline de build. Se uma subpasta de uma pasta mapeada contiver arquivos que o pipeline de build não requer, mapeie-a com um valor de tipo de de Capa.

Verifique se você Mapa todas as pastas que contêm arquivos necessários para o pipeline de build. Por exemplo, se você adicionar outro projeto, talvez seja necessário adicionar outro mapeamento ao workspace.

pastas que você não precisa. Por padrão, a pasta raiz do projeto é mapeada no workspace. Essa configuração resulta no agente de build baixando todos os arquivos na pasta de controle de versão do seu projeto. Se essa pasta contiver muitos dados, seu build poderá desperdiçar recursos do sistema de build e reduzir o pipeline de build baixando grandes quantidades de dados que ele não requer.

Ao remover projetos, procure mapeamentos que podem ser removidos do workspace.

Se esse for um build de CI, na maioria dos casos, você deve verificar se esses mapeamentos correspondem às configurações de filtro do gatilho de CI na guia Gatilhos .

Para obter mais informações sobre como otimizar um workspace do TFVC, consulte Otimizar seu workspace.

Limpar o repositório local no agente

Você pode executar diferentes formas de limpeza do diretório de trabalho do agente auto-hospedado antes que um build seja executado.

Em geral, para obter um desempenho mais rápido de seus agentes auto-hospedados, não limpe o repositório. Nesse caso, para obter o melhor desempenho, verifique se você também está compilando incrementalmente, desabilitando qualquer opção Limpar da tarefa ou ferramenta que você está usando para compilar.

Se você precisar limpar o repositório (por exemplo, para evitar problemas causados por arquivos residuais de uma compilação anterior), suas opções para isso são descritas abaixo.

Se você quiser limpar o repositório, selecione verdadeiroe, em seguida, selecione uma das seguintes opções:

• Fontes: o pipeline de build executa uma desfazer de quaisquer alterações e queima o workspace atual em $(Build.SourcesDirectory).

• Diretório de fontes e saída: a mesma operação que a opção Fontes acima e que, além disso, exclui e recria $(Build.BinariesDirectory).

• Diretório de fontes: exclui e recria $(Build.SourcesDirectory).

• Todos os diretórios de build: exclui e recria $(Agent.BuildDirectory).

Gatilhos de CI

Selecione Habilitar integração contínua na guia Gatilhos para habilitar esse gatilho se você quiser que o build seja executado sempre que alguém fizer check-in de código.

Alterações em lote

Marque essa caixa de seleção se você tiver muitos membros da equipe carregando alterações com frequência e quiser reduzir o número de builds que está executando. Se você selecionar essa opção, quando um build estiver em execução, o sistema aguardará até que o build seja concluído e enfileira outro build de todas as alterações que ainda não foram criadas.

Você pode fazer alterações em lote e compilá-las juntas.

Filtros de caminho

Selecione os caminhos de controle de versão que você deseja incluir e excluir. Na maioria dos casos, você deve garantir que esses filtros sejam consistentes com seus mapeamentos TFVC. Você pode usar filtros de caminho para reduzir o conjunto de arquivos que deseja disparar um build.

Dicas:

• Os caminhos são sempre especificados em relação à raiz do workspace.
• Se você não definir filtros de caminho, a pasta raiz do workspace será incluída implicitamente por padrão.
• Se você excluir um caminho, também não poderá incluí-lo, a menos que o qualifique para uma pasta mais profunda. Por exemplo, se você excluir /tools, poderá incluir /tools/trigger-runs-on-these
• A ordem dos filtros de caminho não importa.

Check-in fechado

Você pode usar o marcar fechado para proteger contra alterações interruptivas.

Por padrão, a opção Usar mapeamentos de workspace para filtros está selecionada. Os builds são disparados sempre que uma alteração é verificada em um caminho especificado em seus mapeamentos de origem.

Caso contrário, você poderá desmarcar essa caixa de seleção e especificar os caminhos no gatilho.

Como isso afeta seus desenvolvedores

Quando os desenvolvedores tentam fazer check-in, eles são solicitados a criar suas alterações.

Em seguida, o sistema cria um conjunto de prateleiras e o cria.

Para obter detalhes sobre a experiência de check-in fechada, consulte Fazer check-in em uma pasta controlada por um pipeline de build de check-in fechado.

Opção para executar builds de CI

Por padrão, os builds de CI não são executados após a conclusão do processo de check-in fechado e as alterações são verificadas.

No entanto, se você quiser que os builds de CI sejam executados após um check-in fechado, selecione a caixa de seleção Executar gatilhos de CI para alterações confirmadas caixa de seleção. Quando você faz isso, o pipeline de build não adiciona ***NO_CI*** à descrição do conjunto de alterações. Como resultado, os builds de CI afetados pelo check-in são executados.

Algumas outras coisas para saber

• Verifique se as pastas que você inclui no gatilho também estão incluídas nos mapeamentos do workspace.
• Você pode executar builds fechados em um agente hospedado pela Microsoft ou em um agente auto-hospedado .

perguntas frequentes

Recebo o seguinte erro ao executar um pipeline:

The shelveset <xyz> could not be found for check-in

• Seu escopo de autorização de trabalho está definido como coleção? Os repositórios do TFVC geralmente são distribuídos entre os projetos em sua coleção. Você pode estar lendo ou gravando em uma pasta que só pode ser acessada quando o escopo é a coleção inteira. Você pode definir isso nas configurações da organização ou na configuração do projeto na guia pipelines do.

Recebo o seguinte erro ao executar um pipeline:

The underlying connection was closed: An unexpected error occurred on a receive. ##[error]Exit code 100 returned from process: file name 'tf', arguments 'vc workspace /new /___location:local /permission:Public

• Geralmente, esse é um erro intermitente causado quando o serviço está enfrentando problemas técnicos. Execute novamente o pipeline.

O que é queimadura?

O Scorch é uma ferramenta de energia TFVC que garante que o controle do código-fonte no servidor e no disco local sejam idênticos. Consulte do Microsoft Visual Studio Team Foundation Server 2015 Power Tools.