Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022
Ao liberar um pacote, é crucial garantir que todas as dependências desse pacote estejam disponíveis no feed consumindo-as de uma fonte upstream. Depois de consumir um pacote de uma fonte upstream, uma cópia é salva no feed. Isso garante que, mesmo que a fonte original se torne inacessível, sua cópia continuará disponível para você e os consumidores do seu feed.
Como as origens constroem o conjunto de pacotes disponíveis
Como os feeds do Azure Artifacts podem ter outros feeds como upstreams, há um potencial para criar ciclos de fontes upstream, onde o feed A upstream para o feed B, que upstream para o feed C, e, eventualmente, o feed C upstream de volta para o feed A. Esse ciclo, se não gerenciado corretamente, pode levar a problemas com solicitações de pacote, criando um loop infinito onde um usuário solicita um pacote do feed A, então A solicita de B, depois B solicita de C, e, finalmente, C solicita de volta para A, formando um loop.
As fontes upstream são projetadas para evitar essas situações. Quando um feed procura um pacote de suas fontes upstream, ele recebe os pacotes na exibição configurada para essa fonte upstream. Isso significa que consultar o feed A não dispara uma consulta transitiva para o feed C (A -> B -> C) porque a exibição é somente leitura. Como resultado, o feed A terá acesso a todos os pacotes de C que foram salvos anteriormente em B por um usuário, mas não o conjunto completo de pacotes disponíveis em C.
Isso coloca a responsabilidade no feed B para garantir que seus pacotes locais representem um grafo de dependência completo. Ao fazer isso, os usuários que consomem o pacote do B por meio de uma fonte upstream de outro feed podem resolver com êxito o grafo e instalar o pacote B desejado sem encontrar problemas.
Exemplo: construir o conjunto de pacotes disponíveis
Vamos considerar três feeds: Fabrikam, Contoso e AdventureWorks. Nesta ilustração, examinaremos os pacotes disponíveis no feed da Fabrikam à medida que apresentamos fontes upstream.
Inicialmente, a Fabrikam não tem fontes upstream, permitindo que os usuários conectados à Fabrikam instalem apenas as versões 1.0.0 e 2.0.0 do pacote Widgets. Da mesma forma, a Contoso não tem fontes upstream, restringindo os usuários conectados à Contoso para instalar apenas as versões 1.0.0 e 3.0.0 do pacote gizmos. O mesmo se aplica ao feed adventureworks, em que os usuários conectados só podem instalar as versões 1.0.0 e 2.0.0 do pacote gadgets ou versão 1.0.0 do pacote Coisas.
Agora, vamos explorar o cenário em que a Contoso adiciona o AdventureWorks como uma fonte upstream. Quando um usuário está conectado à Contoso, ele obtém acesso a uma gama mais ampla de pacotes. Eles podem instalar qualquer versão do Gizmos, Gadgets ou Things. Por exemplo, se o usuário instalar Gadgets@2.0.0, essa versão específica do pacote será salva na Contoso com um link de volta para o AdventureWorks.
Agora, vamos considerar uma situação em que o feed da Fabrikam adiciona Contoso como uma fonte principal. Um usuário conectado à Fabrikam pode instalar qualquer versão dos Widgets, qualquer versão dos Gizmos, mas somente versões SALVAS dos Gadgets (2.0.0).
O usuário não poderá instalar a versão 1.0.0 do Gadgets ou qualquer versão do Things, pois essas versões do pacote não foram salvas na Contoso por um usuário da Contoso.
