Esta página explica como especificar dependências de build. O Cloud Build permite gerenciar dependências de código-fonte separadamente do processo de build.
No arquivo de configuração do build, é possível listar um ou mais repositórios para clonar para o build e a ordem em que eles serão buscados. Especificar dependências dessa forma separa a busca de dependências do processo de build.
Se você não incluir nenhuma dependência no arquivo de configuração do build, o Cloud Build vai clonar o repositório de código-fonte que contém o arquivo de configuração do build (para builds acionados) ou o repositório que contém o código-fonte (para builds invocados na linha de comando). Se você incluir dependências no arquivo de configuração do build, o Cloud Build vai clonar apenas os repositórios especificados no campo dependencies.
As dependências são clonadas na ordem em que você as especifica. Além disso, a busca de dependências ocorre antes que qualquer lógica especificada pelo usuário seja executada. Portanto, a busca de dependências é confiável.
As dependências são mostradas na guia Dependências do build da página Detalhes do build.
Antes de começar
As instruções nesta página pressupõem que você tenha pelo menos um dos dois tipos de repositório a seguir:
Um repositório Git público ou vinculado ao Cloud Build usando o Developer Connect.
Um repositório genérico.
Para garantir que tenha as permissões necessárias para adicionar um repositório do Developer Connect como uma dependência, peça ao administrador para conceder o papel do IAM de leitor de token do Developer Connect (developerconnect.readTokenAccessor) a na sua conta de serviço.
Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.
Seu administrador também pode conceder as permissões necessárias por meio de papéis personalizados ou outros papéis predefinidos.
Especificar as dependências
Para especificar dependências, adicione um campo dependencies ao arquivo de configuração do build. dependencies é uma propriedade de nível superior na configuração do build, mas você pode colocá-la em qualquer lugar do arquivo.
Especificar dependências do GitHub
Para especificar uma dependência em um repositório do GitHub, adicione a seguinte configuração dependencies ao arquivo de configuração do build:
YAML
dependencies:
- gitSource:
repository:
url: 'URL'
developerConnect: 'DC_RESOURCE_PATH'
revision: 'REVISION'
recurseSubmodules: 'true|false'
fetchTags: 'true|false'
depth: 'DEPTH'
destPath: 'DEST_PATH'
JSON
{
"dependencies": {
"gitSource": {
"repository": {
"url": "URL"
"developerConnect": "DC_RESOURCE_PATH"
},
"revision": "REVISION",
"recurseSubmodules": true|false,
"fetchTags": true|false,
"depth": "DEPTH",
"destPath": "DEST_PATH",
},
},
}
Substitua os seguintes valores:
URL: o URL HTTPS do repositório a ser buscado. Obrigatório, a menos que o repositório esteja conectado ao Cloud Build usando o Developer Connect.
DC_RESOURCE_PATH: O caminho de Google Cloud recurso para um repositório do Developer Connect. Por exemplo,
projects/my-project/locations/us-central1/connections/my-connection/gitRepositoryLinks/my-repo. Obrigatório se o repositório estiver conectado ao Cloud Build usando o Developer Connect.Se o repositório estiver conectado usando o Developer Connect, você precisará do seguinte:
- A conta de serviço do Cloud Build precisa ter o
Developer Connect Read Token Accessorpapel.
- A conta de serviço do Cloud Build precisa ter o
REVISION: obrigatório. A versão, o hash de confirmação, a tag ou o nome da ramificação a ser buscado no repositório.
recurseSubmodules: "true|false": se os submódulos serão buscados.fetchTags: 'true|false': opcional. Verdadeiro se as tags remotas também precisarem ser buscadas (padrãofalse). Observação: quandodepthé1(padrão),git fetchsó recupera tags que apontam para confirmações dentro do limite superficial. Definadepthcomo-1para buscar todas as tags históricas.DEPTH: opcional, a profundidade do histórico do repositório a ser buscado. Se não for especificado, a confirmação mais recente será buscada.
1: a confirmação mais recente2: as duas últimas confirmações3: as três últimas confirmações-1: todas as confirmações
DEST_PATH: obrigatório. O caminho para o diretório em que o repositório é clonado. Por exemplo,
my/repo.Quando você define o
dest_path, o repositório é buscado em/workspace/<dest_path>. O valordest_pathprecisa ser um caminho relativo ao diretório de trabalho do build.
Especificar um artefato genérico como dependência
Para especificar um
artefato genérico
como dependência, adicione a seguinte configuração dependencies ao arquivo de configuração do build:
YAML
dependencies:
- genericArtifact:
resource: RESOURCE
destPath: PATH
JSON
{
"dependencies": [
{
"genericArtifact": {
"resource": "RESOURCE",
"destPath": "PATH"
}
}
]
}
Em que:
RESOURCE é o endereço completo do artefato genérico no repositório genérico do Artifact Registry, formatado da seguinte maneira:
projects/PROJECT/locations/LOCATION/repositories/REPOSITORY/packages/PACKAGE/versions/VERSIONRecomendamos incluir a impressão digital do artefato no endereço do recurso para que o Cloud Build possa verificar se a referência do artefato é imutável. Uma versão do pacote com uma impressão digital anexada é formatada da seguinte maneira:
VERSION@dirsum_sha256=HASH_VALUEPara encontrar a impressão digital de um artefato em um repositório do Artifact Registry, consulte Recuperar a impressão digital de uma versão do pacote no repositório.
PATH é o endereço da pasta para a qual o Cloud Build faz o download do pacote do repositório. Se a pasta ainda não existir, o Cloud Build a criará automaticamente.
A seguir
Saiba como conectar um repositório ao Cloud Build usando repositórios do Cloud Build.
Saiba como conectar um repositório ao Cloud Build usando o Developer Connect.