Gerenciar dependências do build

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:

  • 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ão false). Observação: quando depth é 1 (padrão), git fetch só recupera tags que apontam para confirmações dentro do limite superficial. Defina depth como -1 para 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 recente
    • 2: as duas últimas confirmações
    • 3: 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 valor dest_path precisa 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/VERSION

    Recomendamos 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_VALUE

    Para 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