Criar repositórios Git do TFS ou Git do Azure Repos

Você também pode dizer ao Azure Pipelines para ignorar a execução de um pipeline que um push normalmente dispararia. Basta incluir ***NO_CI*** na mensagem de qualquer um dos commits que fazem parte de um push e o Azure Pipelines ignorará a execução de CI para esse push.

Você também pode dizer ao Azure Pipelines para ignorar a execução de um pipeline que um push normalmente dispararia. Basta incluir [skip ci] na mensagem ou descrição de qualquer um dos commits que fazem parte de um push e o Azure Pipelines ignorará a execução de CI para esse push. Você também pode usar qualquer uma das variações a seguir.

• [skip ci] ou [ci skip]
• skip-checks: true ou skip-checks:true
• [skip azurepipelines] ou [azurepipelines skip]
• [skip azpipelines] ou [azpipelines skip]
• [skip azp] ou [azp skip]
• ***NO_CI***

Validar contribuições de forks

A criação de solicitações de pull de forks do Azure Repos não é diferente da criação de solicitações de pull no mesmo repositório ou projeto. Você pode criar forks somente na mesma organização da qual seu projeto faz parte.

Limitar o escopo de autorização do trabalho

O Azure Pipelines fornece várias configurações de segurança para configurar o escopo de autorização de trabalho com o qual os pipelines são executados.

• Limitar o escopo de autorização de trabalho ao projeto atual
• Proteger o acesso a repositórios em pipelines YAML

Limitar o escopo de autorização de trabalho ao projeto atual

O Azure Pipelines fornece duas configurações Limitar o escopo de autorização de trabalho ao projeto atual:

• Limitar o escopo da autorização de trabalho ao projeto atual para pipelines de não lançamento – essa configuração se aplica a pipelines YAML e pipelines de build clássicos. Ele não se aplica a pipelines de lançamento clássicos.
• Limitar o escopo da autorização de trabalho ao projeto atual para pipelines de lançamento – essa configuração se aplica somente a pipelines de lançamento clássicos.

Os pipelines são executados com tokens de acesso com escopo de coleção, a menos que a configuração relevante para o tipo de pipeline esteja habilitada. As configurações Limitar o escopo de autorização de trabalho permitem reduzir o escopo de acesso de todos os pipelines para o projeto atual. Isso poderá afetar seu pipeline se você estiver acessando um Repositório do Git do Azure Repos em um projeto diferente em sua organização.

Se o seu Repositório do Git do Azure Repos estiver em um projeto diferente do pipeline e a configuração Limitar escopo de autorização de trabalho para o tipo de pipeline estiver habilitada, você precisará conceder permissão à identidade do serviço de build do pipeline para o segundo projeto. Para obter mais informações, confira Gerenciar permissões de conta de serviço de build.

O Azure Pipelines fornece uma configuração de segurança para configurar o escopo de autorização de trabalho com o qual os pipelines são executados.

• Limitar o escopo da autorização de trabalho ao projeto atual – essa configuração se aplica a pipelines YAML e pipelines de build clássicos. Essa configuração não se aplica a pipelines de lançamento clássicos.

Os pipelines são executados com tokens de acesso com escopo de coleção, a menos que a configuração Limitar o escopo de autorização de trabalho ao projeto atual esteja habilitada. Essa configuração permite reduzir o escopo de acesso de todos os pipelines para o projeto atual. Isso poderá afetar seu pipeline se você estiver acessando um Repositório do Git do Azure Repos em um projeto diferente em sua organização.

Se seu Repositório do Git do Azure Repos estiver em um projeto diferente do pipeline e a configuração Limitar o escopo de autorização de trabalho estiver habilitada, você precisará conceder permissão à identidade do serviço de build do pipeline para o segundo projeto. Para obter mais informações, confira Escopo da autorização do trabalho.

Para obter mais informações sobre Limitar o escopo de autorização de trabalho, confira Noções básicas de tokens de acesso ao trabalho.

Limitar o escopo da autorização de trabalho para repositórios do Azure DevOps referenciados

Os pipelines podem acessar todos os repositórios do Azure DevOps em projetos autorizados, conforme descrito na seção anterior, Limitar o escopo de autorização de trabalho ao projeto atual, a menos que a configuração Limitar o escopo de autorização de trabalho para repositórios do Azure DevOps referenciados esteja habilitada. Com essa opção habilitada, você pode reduzir o escopo de acesso para todos os pipelines apenas para repositórios do Azure DevOps explicitamente referenciados por uma etapa checkout ou uma instrução uses no trabalho de pipeline que usa esse repositório.

Para definir essa configuração, navegue até Pipelines, Configurações em Configurações da organização ou em Configurações do projeto. Se habilitada no nível da organização, a configuração ficará esmaecida e indisponível no nível de configurações do projeto.

Quando Limitar o escopo de autorização de trabalho para repositórios do Azure DevOps referenciados estiver habilitada, seus pipelines YAML precisarão referenciar explicitamente todos os repositórios Git do Azure Repos que você deseja usar no pipeline como etapa de check-out no trabalho que usa o repositório. Você não poderá efetuar fetch de código usando tarefas de script e comandos git para um Repositório do Git do Azure Repos, a menos que esse repositório seja referenciado explicitamente primeiro.

Há algumas exceções em que você não precisa referenciar explicitamente um Repositório do Git do Azure Repos antes de usá-lo em seu pipeline quando a configuração Limitar o escopo de autorização de trabalho para repositórios do Azure DevOps referenciados está habilitada.

• Se você não tiver uma etapa de check-out explícita em seu pipeline, será como se você tivesse uma etapa checkout: self e o check-out do repositório self tivesse sido feito.
• Se você estiver usando um script para executar operações somente leitura em um repositório em um projeto público, não precisará referenciar o repositório de projeto público em uma etapa checkout.
• Se você estiver usando um script que fornece a própria autenticação para o repositório, como um PAT, não será necessário fazer referência a esse repositório em uma etapa checkout.

Por exemplo, quando a configuração Limitar o escopo de autorização de trabalho para repositórios do Azure DevOps referenciados estiver habilitada, se o pipeline estiver no repositório FabrikamProject/Fabrikam em sua organização e você quiser usar um script para fazer check-out do repositório FabrikamProject/FabrikamTools, você precisará referenciar esse repositório em uma etapa checkout ou com uma instrução uses.

Se você já estiver verificando o repositório FabrikamTools em seu pipeline usando uma etapa de check-out, poderá usar scripts posteriormente para interagir com esse repositório.

steps:
- checkout: git://FabrikamFiber/FabrikamTools # Azure Repos Git repository in the same organization
- script: # Do something with that repo

# Or you can reference it with a uses statement in the job
uses:
  repositories: # List of referenced repositories
  - FabrikamTools # Repository reference to FabrikamTools

steps:
- script: # Do something with that repo like clone it

Proteger o acesso a repositórios em pipelines YAML

Os pipelines podem acessar todos os repositórios do Azure DevOps em projetos autorizados, conforme descrito na seção anterior, Limitar o escopo de autorização de trabalho ao projeto atual, a menos que Proteger o acesso a repositórios em pipelines YAML esteja habilitada. Com essa opção habilitada, você pode reduzir o escopo de acesso para todos os pipelines apenas para repositórios do Azure DevOps explicitamente referenciados por uma etapa checkout ou uma instrução uses no trabalho de pipeline que usa esse repositório.

Para definir essa configuração, navegue até Pipelines, Configurações em Configurações da organização ou em Configurações do projeto. Se habilitada no nível da organização, a configuração ficará esmaecida e indisponível no nível de configurações do projeto.

Há algumas exceções em que você não precisa referenciar explicitamente um Repositório do Git do Azure Repos antes de usá-lo em seu pipeline quando Proteger o acesso a repositórios em pipelines YAML está habilitado.

• Se você não tiver uma etapa de check-out explícita em seu pipeline, será como se você tivesse uma etapa checkout: self e o check-out do repositório self tivesse sido feito.
• Se você estiver usando um script para executar operações somente leitura em um repositório em um projeto público, não precisará referenciar o repositório de projeto público em uma etapa checkout.
• Se você estiver usando um script que fornece a própria autenticação para o repositório, como um PAT, não será necessário fazer referência a esse repositório em uma etapa checkout.

Por exemplo, quando a configuração Proteger o acesso a repositórios em pipelines YAML estiver habilitada, se o pipeline estiver no repositório FabrikamProject/Fabrikam em sua organização e você quiser usar um script para fazer check-out do repositório FabrikamProject/FabrikamTools, você precisará referenciar esse repositório em uma etapa checkout ou com uma instrução uses.

Se você já estiver verificando o repositório FabrikamTools em seu pipeline usando uma etapa de check-out, poderá usar scripts posteriormente para interagir com esse repositório.

steps:
- checkout: git://FabrikamFiber/FabrikamTools # Azure Repos Git repository in the same organization
- script: # Do something with that repo
# Or you can reference it with a uses statement in the job
uses:
  repositories: # List of referenced repositories
  - FabrikamTools # Repository reference to FabrikamTools
steps:
- script: # Do something with that repo like clone it

Check-out

Quando um pipeline é disparado, o Azure Pipelines efetua pull do código-fonte do Repositório do Git do Azure Repos. Você pode controlar vários aspectos de como isso acontece.

Versão preferencial do Git

O agente do Windows vem com uma cópia própria do Git. Se você preferir fornecer seu Git em vez de usar a cópia incluída, defina System.PreferGitFromPath como true. Essa configuração é sempre verdadeira em agentes que não são do Windows.

Caminho de check-out

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Submódulos

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

O pipeline de build fará check-out de seus submódulos do Git, desde que eles sejam de um dos seguintes tipos:

• Não autenticado: um repositório público não autenticado sem necessidade de credenciais para clonar ou efetuar fetch.

• Autenticado:

  • contido no mesmo projeto que o Repositório do Git do Azure Repos especificado acima. As mesmas credenciais usadas pelo agente para obter as fontes do repositório main também são usadas para obter as fontes de submódulos.

  • Adicionado usando uma URL relativa ao repositório main. Por exemplo

    • O check-out deste seria realizado: git submodule add ../../../FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

      Neste exemplo, o submódulo refere-se a um repositório (FabrikamFiber) na mesma organização do Azure DevOps, mas em um projeto diferente (FabrikamFiberProject). As mesmas credenciais usadas pelo agente para obter as fontes do repositório main também são usadas para obter as fontes de submódulos. Isso exige que o token de acesso ao trabalho tenha acesso ao repositório no segundo projeto. Se você tiver restringido o token de acesso ao trabalho, conforme explicado na seção acima, não poderá fazer isso. Você pode permitir que o token de acesso ao trabalho acesse o repositório no segundo projeto, (a) concedendo explicitamente acesso à conta de serviço de build do projeto no segundo projeto ou (b) usando tokens de acesso com escopo de coleção em vez de tokens com escopo de projeto para toda a organização. Para obter mais informações sobre essas opções e as respectivas implicações de segurança, confira Repositórios de acesso, artefatos e outros recursos.

    • O check-out deste não seria realizado: git submodule add https://fabrikam-fiber@dev.azure.com/fabrikam-fiber/FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

Alternativa ao uso da opção Fazer check-out de submódulos

Em alguns casos, você não pode usar a opção Fazer check-out de submódulos. Você pode ter um cenário em que um conjunto diferente de credenciais é necessário para acessar os submódulos. Isso poderá acontecer, por exemplo, se o repositório main e os repositórios de submódulo não forem armazenados na mesma organização do Azure DevOps ou se o token de acesso ao trabalho não tiver acesso ao repositório em um projeto diferente.

Se você não puder usar a opção Fazer checkout de submódulos, poderá usar uma etapa de script personalizada para efetuar fetch de submódulos. Obtenha um PAT (token de acesso pessoal) e prefixe-o com pat:. Depois, codifique essa cadeia de caracteres prefixada em base64 para criar um token de autenticação básico. Por fim, adicione este script ao pipeline:

git -c http.https://<url of submodule repository>.extraheader="AUTHORIZATION: Basic <BASE64_ENCODED_STRING>" submodule update --init --recursive

Substitua "<BASE64_ENCODED_STRING>" pela cadeia de caracteres "pat:token" codificada em Base64.

Use uma variável secreta em seu projeto ou pipeline de build para armazenar o token de autenticação básico gerado. Use essa variável para preencher o segredo no comando Git acima.

Sincronizar tags

A etapa de check-out usa a opção --tags ao efetuar fetch do conteúdo de um Repositório do Git. Isso faz com que o servidor efetue fetch de todas as tags, bem como todos os objetos apontados por essas tags. Isso aumenta o tempo para executar a tarefa em um pipeline, especialmente se você tiver um repositório grande com várias tags. Além disso, a etapa de check-out sincroniza tags mesmo quando você habilita a opção de fetch superficial, anulando a utilidade dela. Para reduzir a quantidade de dados buscados ou extraídos de um Repositório do Git, a Microsoft adicionou uma nova opção de check-out para controlar o comportamento das tags de sincronização. Essa opção está disponível em pipelines clássicos e YAML.

Se as tags devem ou não ser sincronizadas ao fazer check-out de um repositório é algo que pode ser configurado no YAML pela definição da propriedade fetchTags e na interface do usuário pela configuração Sincronizar tags.

steps:
- checkout: self
  fetchTags: true

Comportamento padrão

• Para pipelines existentes criados antes do lançamento do Azure DevOps sprint 209, lançado em setembro de 2022, o padrão para sincronizar marcas permanece o mesmo que o comportamento existente antes da adição das opções Sincronizar tags, que é true.
• Para novos pipelines criados após a versão 209 do Azure DevOps sprint, o padrão para sincronizar tags é false.

Fetch superficial

Talvez você queira limitar de quão anteriormente o histórico deve ser baixado. Efetivamente, isso resulta em git fetch --depth=n. Se o repositório for grande, essa opção poderá tornar o pipeline de build mais eficiente. Seu repositório poderá ser grande se estiver em uso por um longo tempo e tiver um histórico considerável. Também poderá ser grande se você tiver adicionado e excluído arquivos grandes posteriormente.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Nesses casos, essa opção pode ajudar você a conservar recursos de rede e armazenamento. Ela também pode economizar tempo. O motivo pelo qual ela nem sempre economiza tempo é porque, em algumas situações, o servidor pode precisar gastar tempo calculando os commits a serem baixados para obter a profundidade especificada.

Não sincronizar fontes

Talvez você queira ignorar o fetch de novos commits. Essa opção pode ser útil em casos em que você deseja:

• Usar git init, config e fetch usando suas opções personalizadas.

• Usar um pipeline de build para executar apenas a automação (por exemplo, alguns scripts) que não dependem do código no controle de versão.

steps:
- checkout: none  # Don't sync sources

Limpar build

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.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

git clean -ffdx
git reset --hard HEAD

jobs:
- job: string  # name of the job, A-Z, a-z, 0-9, and underscore
  ...
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs

Fontes de rótulo

Talvez você queira rotular seus arquivos de código-fonte para permitir que sua equipe identifique facilmente qual versão de cada arquivo está incluída no build concluído. Você também tem a opção de especificar se o código-fonte deve ser rotulado para todos os builds ou apenas para builds bem-sucedidos.

Em Formato de tag, você pode usar variáveis definidas pelo usuário e predefinidas que têm um escopo de "Todos". Por exemplo:

$(Build.DefinitionName)_$(Build.DefinitionVersion)_$(Build.BuildId)_$(Build.BuildNumber)_$(My.Variable)

As quatro primeiras variáveis são predefinidas. My.Variable pode ser definido por você na guia variáveis.

O pipeline de build rotula suas fontes com uma Tag do git.

Algumas variáveis de build podem produzir um valor que não é um rótulo válido. Por exemplo, variáveis como $(Build.RequestedFor) e $(Build.DefinitionName) podem conter um espaço em branco. Se o valor contiver um espaço em branco, a marca não será criada.

Depois que as fontes são marcadas pelo pipeline de build, um artefato do Git com a referência refs/tags/{tag} é adicionado automaticamente ao build concluído. Isso oferece à sua equipe rastreabilidade adicional e uma maneira mais amigável de navegar do build para o código que foi compilado. A tag é considerada um artefato de build, pois é produzida pelo build. Quando o build é excluído manualmente ou por meio de uma política de retenção, a marca também é excluída.