Ligar um Repositório do Azure DevOps

Orbit implementa a partir do Azure Repos, o alojamento git dentro do Azure DevOps. Conecte uma vez, escolha um repositório, e cada push constrói e fica ativo. Este guia cobre ambas as formas de conectar, selecionar um repositório, e as duas coisas que o Azure faz de forma diferente dos outros fornecedores.

Duas Formas De Conectar, E Por Que Existem Duas

As organizações Azure DevOps podem bloquear aplicações de terceiros ao nível do inquilino, e muitas empresas fazem-no. Se a sua o fizer, o botão de início de sessão não pode funcionar para você não importa o que façamos, por isso o Orbit oferece uma segunda porta que funciona sempre.

• Iniciar sessão com Microsoft. Um clique, nada para copiar e colar. Disponível quando a sua organização permite aplicações de terceiros.
• Token de acesso pessoal. Funciona para cada organização, incluindo as que bloqueiam aplicações. Você cola um nome de organização e um token que cria no Azure DevOps.

Ambas as portas acedem exatamente às mesmas funcionalidades. Nenhuma é uma versão reduzida da outra.

Antes De Começar

Opção A: Iniciar Sessão Com Microsoft

1. No KPanel, clique em Orbit na barra lateral esquerda.
2. Clique em Novo projeto.
3. Deixe o modo definido como Importar Repo Git.
4. Escolha o separador Azure DevOps e depois clique em Conectar Azure DevOps.

Você é enviado para a Microsoft para iniciar sessão e aprovar o acesso. Aprove-o e será devolvido ao KPanel com os seus repositórios carregados.

Se a sua organização bloquear a aplicação, a Microsoft recusa e o KPanel mostra o motivo que deu. Isso não é algo que possa repetir: use o token de acesso pessoal abaixo, ou peça a um administrador para permitir a aplicação.

Opção B: Token De Acesso Pessoal

Crie o token no Azure DevOps primeiro.

1. No Azure DevOps, abra Definições de utilizador, depois Tokens de acesso pessoal, depois Novo Token.
2. Escolha a organização de que pretende implementar.
3. Conceda estes três âmbitos e apenas estes três:
   • Code (Read) para que o Orbit possa listar os seus repositórios e descarregar o commit que está a construir.
   • Code (Status) para que o resultado da construção apareça no commit e no pedido de pull.
   • Service Hooks (Read and write) para que o Orbit possa subscrever os seus pushes.
4. Copie o token. O Azure mostra-o uma vez.

Depois no KPanel:

1. Abra Orbit, depois Novo projeto, depois o separador Azure DevOps.
2. Sob Conectar com um token de acesso pessoal, introduza o seu nome de organização. Essa é a parte do seu endereço de repositório imediatamente após dev.azure.com, portanto para https://dev.azure.com/contoso/web-platform/_git/storefront a organização é contoso.
3. Cole o token e clique em Conectar Azure DevOps.

O Orbit utiliza o token imediatamente para listar os seus repositórios. Se for recusado, é-lhe dito quais os âmbitos que faltam em vez de ser-lhe pedido para verificar o seu token, porque um token que lista repositórios mas não consegue criar um hook de serviço é a forma que se conecta limpar e depois nunca implementa nada.

O seu token é encriptado antes de ser armazenado e é apenas utilizado contra a organização que nomeou.

Selecionar Um Repositório

Os seus repositórios aparecem como uma lista, nomeada organisation / project / repository. Os repositórios Azure têm três partes, não duas, porque dois projetos numa organização podem cada um manter um repositório com o mesmo nome.

Clique em Selecionar junto ao que pretende, depois conclua o projeto como habitualmente: nome, framework, definições de construção, variáveis de ambiente.

Se Um Repositório Estiver Em Falta

• Verifique a organização. Um token de acesso pessoal pertence a UMA organização, portanto um repositório numa diferente não aparecerá. Conecte também essa organização.
• Verifique o seu acesso no repositório em si no Azure DevOps.
• Verifique se o repositório está desabilitado no Azure. O Orbit não lista repositórios desabilitados, porque não podem ser construídos.

Duas Coisas Que O Azure Faz De Forma Diferente

Estas são diferenças reais, não lacunas que não tenhamos abordado, e ambas são indicadas aqui em vez de descobertas depois.

Diretório Raiz Monorepo Não Ignora Pushes

Nos outros fornecedores, o Orbit lê a lista de ficheiros que cada push alterou, e um projeto monorepo pode ignorar uma construção quando nada sob o seu Diretório Raiz se moveu. O Azure não envia essa lista. O Orbit, portanto, constrói em cada push em vez de adivinhar, porque adivinhar da outra forma ignoraria silenciosamente implementações que estava à espera.

A sua definição de Diretório Raiz ainda decide onde a construção é executada. Apenas não filtra adicionalmente quais os pushes que constroem.

Pedidos de Pull De Forks Não São Construídos

O Orbit constrói uma pré-visualização de pedido de pull com as variáveis de ambiente de Pré-visualização do seu projeto. Isso é seguro para um pedido de pull do seu próprio repositório e não é seguro para um de um fork, que é uma proposta de alguém sem relação com a sua conta.

No GitHub, o Orbit pode oferecer uma pré-visualização de fork porque o GitHub publica o commit proposto dentro do seu próprio repositório, portanto nunca temos de nos autenticar contra a cópia do contribuidor. O Azure não publica um equivalente, portanto o Orbit recusa pedidos de pull de forks e diz-o no commit em vez de deixar uma pré-visualização que nunca aparece.

Os pedidos de pull de ramos dentro do seu próprio repositório constroem normalmente.

O Que Acontece A Seguir

Faça push para o seu ramo de produção e o Orbit constrói e implementa. O resultado da construção é publicado de volta no commit no Azure DevOps, portanto aparece no commit e em qualquer pedido de pull a que o commit pertence, e as suas políticas de ramo podem exigi-lo.

Ver Também

• O que é Orbit?
• Implementar o Seu Projeto
• Ligar um Repositório GitHub