Como criar repositórios do GitHub

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Com os gatilhos do GitHub, é possível criar automaticamente em solicitações de envio e pull do Git e ver os resultados de compilação no GitHub e no Console do Google Cloud. Além disso, os gatilhos do GitHub aceitam todos os recursos suportados pelos gatilhos atuais do GitHub e usam o app Cloud Build GitHub para configurar e autenticar no GitHub.

Nesta página, explicamos como criar gatilhos do GitHub e criá-los no GitHub usando o app GitHub do Cloud Build.

Antes de começar

  • Ative a API Cloud Build.

    Ative a API

Como criar um gatilho do GitHub

Console

Para criar gatilhos do GitHub usando o Console do Google Cloud:

  1. Abra a página Gatilhos no console do Google Cloud.

    Abrir a página Acionadores

  2. Selecione o projeto no menu suspenso do seletor de projetos na parte superior da página.

  3. Clique em Abrir.

  4. Clique em Criar gatilho.

  5. Preencha as configurações de gatilho a seguir:

    • Nome: insira um nome para o gatilho.

    • Região: selecione a região do acionador.

      • Se você selecionar global como a região, o Cloud Build usará o pool padrão para executar seu build.
      • Se você selecionar uma região não global e o arquivo de configuração do build associado ao gatilho especificar um pool privado, o Cloud Build usará o pool privado para executar a versão. Nesse caso, a região especificada no gatilho precisa corresponder à região onde você criou o pool privado.
      • Se você selecionar uma região não global e o arquivo de configuração do build associado ao gatilho não especificar um pool privado, o Cloud Build usará o pool padrão para executar a versão na mesma região do gatilho.
    • Descrição (opcional): insira uma descrição para o gatilho.

    • Evento: selecione o evento de repositório para invocar seu gatilho.

      • Enviar para uma ramificação: defina o gatilho para iniciar um build em confirmações de uma ramificação específica.

      • Enviar nova tag por push: configure o gatilho para iniciar um build em confirmações que contenham uma tag específica.

      • Solicitação de envio (o Cloud Source Repositories não é compatível): defina o gatilho para iniciar uma versão em confirmações de uma solicitação de envio.

    • Origem: selecione o repositório e a ramificação ou tag correspondente para assistir aos eventos.

      • Repositório: na lista de repositórios disponíveis, selecione o repositório que você quer. Para conectar um novo repositório, consulte Como conectar mais repositórios.

      • Ramificação ou Tag: especifique uma expressão regular correspondente ao valor da ramificação ou da tag. Para ver informações sobre a sintaxe aceitável de expressões regulares, consulte Sintaxe de RE2 (em inglês).

      • Controle de comentários: se você selecionou Solicitação de envio (somente aplicativo GitHub) como seu Evento, escolha uma das seguintes opções para controlar se um build será executado automaticamente pelo gatilho:

        • Obrigatório, exceto para proprietários e colaboradores: quando uma solicitação de envio for criada ou atualizada por um proprietário ou colaborador de repositório, os builds são executados automaticamente pelo gatilho. Se um colaborador externo iniciar a ação, os builds serão executadas somente depois que um proprietário ou colaborador comentar a /gcbrun na solicitação de envio.

        • Obrigatório: quando uma solicitação de envio é criada ou atualizada por qualquer colaborador, os builds só serão executados depois que um proprietário ou colaborador comentar /gcbrun na solicitação de envio. Os builds são executados sempre que uma alteração em uma solicitação de envio é feita.

        • Não necessário: quando uma solicitação de envio é criada ou atualizada por qualquer colaborador, os builds são executados automaticamente por gatilhos.

    • Arquivos incluídos (opcional): as alterações que afetam pelo menos um desses arquivos invocarão um build.

    • Arquivos ignorados (opcional): as alterações que afetam somente os arquivos ignorados não invocarão um build.

    • Configuração: selecione o arquivo de configuração da versão localizado no seu repositório remoto ou crie um arquivo de configuração de versão in-line para usar na versão.

      • Tipo: selecione o tipo de configuração a ser usado para seu build.
        • Detectado automaticamente: o Cloud Build detecta seu tipo de configuração se você tiver um cloudbuild.yaml ou Dockerfile no repositório.
        • Arquivo de configuração do Cloud Build (yaml ou json): use um arquivo de configuração do build na sua configuração.
        • Dockerfile: use um Dockerfile para sua configuração.
        • Buildpacks: use os buildpacks na sua configuração.
      • Local: especifique o local de configuração.

        • Repositório: se o arquivo de configuração estiver no seu repositório remoto, forneça o local do arquivo de configuração do build ou Dockerfile } e um nome para a imagem resultante. Se sua configuração for um Dockerfile, você poderá fornecer um tempo limite para a criação. Depois de fornecer o Dockerfile e o nome da imagem, você verá uma visualização do comando docker build que sua o build executará.
        • Inline: se você selecionou o arquivo de configuração do Cloud Build (yaml ou json) como opção de configuração, pode especificar a configuração do build inline. Clique em Abrir editor para escrever o arquivo de configuração do build no console do Google Cloud usando a sintaxe YAML ou JSON. Clique em Concluído para salvar a configuração do build.
    • Variáveis de substituição (opcional): se você tiver selecionado o arquivo de configuração do Cloud Build como sua opção de configuração da versão, poderá definir variáveis de substituição específicas do acionador usando esse campo. Por exemplo, vamos supor que você esteja criando vários gatilhos em que cada um deles implanta seu app em um ambiente específico. É possível especificar que seu app seja implantado em um ambiente em seu arquivo de configuração da compilação e usar esse campo para definir variáveis de substituição especificando em qual ambiente esse gatilho deverá ser implantado. Para informações sobre como especificar valores de substituição em arquivos de configuração da compilação, consulte Como substituir valores de variável.

    • Aprovação (opcional): marque a caixa para exigir a aprovação antes da execução da versão. Para saber mais sobre aprovações, consulte Criar builds com aprovação.

    • Build logs (opcional): marque a caixa para enviar registros do build para o GitHub. Para saber como ver registros de compilação, consulte Visualizar registros de compilação.

    • Conta de serviço: selecione a conta de serviço a ser usada ao invocar seu gatilho. Se você não selecionar uma conta de serviço, a conta de serviço padrão do Cloud Build será usada.

  6. Clique em Criar para salvar o gatilho de compilação.

Para criar acionadores do GitHub usando comandos gcloud, consulte os comandos gcloud para Como criar um gatilho de compilação.

gcloud

Para criar gatilhos do GitHub usando comandos gcloud, execute o seguinte comando:

gcloud beta builds triggers create github \
    --repo-name=REPO_NAME \
    --repo-owner=REPO_OWNER \
    --branch-pattern=BRANCH_PATTERN \ # or --tag-pattern=TAG_PATTERN
    --build-config=BUILD_CONFIG_FILE \
    --include-logs-with-status

Em que:

  • REPO_NAME é o nome do repositório;
  • REPO_OWNER é o nome de usuário do proprietário do repositório.
  • BRANCH_PATTERN é o nome da ramificação no seu repositório para invocar o build.
  • TAG_PATTERN é o nome da tag no repositório para invocar o build.
  • BUILD_CONFIG_FILE é o caminho para seu arquivo de configuração da compilação.
  • [OPCIONAL] --include-logs-with-status é uma sinalização que pode ser especificada para mostrar registros de versão dos seus repositórios. Essa sinalização é compatível com versões dos repositórios do GitHub e do GitHub Enterprise. Para saber como ver registros de compilação, consulte Como visualizar registros de compilação.

Como criar e visualizar as alterações

Para criar usando gatilhos do GitHub, você precisará enviar e confirmar alterações para seu repositório de origem conectado ou configurar seu build em solicitações de envio. Depois de verificar as alterações, o Cloud Build criará o código.

Para ver as alterações no build no GitHub, acesse a guia Verificações no seu repositório.

Captura de tela da guia de conversa

Você verá que o Cloud Build criou as alterações. Você também verá outros detalhes da build, como o tempo que levou para criar o código, o código da build.

Para ver as alterações do build no Cloud Build, clique em Ver mais detalhes no Google Cloud Build. A página Detalhes do build no console do Google Cloud é aberta para que você possa ver as informações do build, como status, registros e etapas do build.

Diferentes tipos de gatilhos com base no GitHub

Se seu código-fonte estiver em GitHub, o Cloud Build fornecerá duas maneiras de executar versões automaticamente. Esta seção explica e compara os recursos dos dois acionadores com base no GitHub.

  • Gatilhos legados do GitHub: quando você cria um gatilho legado do GitHub, o Cloud Build espelha o repositório do GitHub no Cloud Source Repositories e usa o repositório espelhado em todas as operações. É possível criar e gerenciar gatilhos do GitHub usando o console do Google Cloud.

  • Gatilhos do GitHub: esse tipo de acionador usa o aplicativo do GitHub para Cloud Build para a configuração e autenticação do GitHub. Os gatilhos do GitHub permitem iniciar automaticamente as versões em solicitações push e pull do Git e ver os resultados do build no GitHub e no console do Google Cloud. É possível criar e gerenciar gatilhos do GitHub usando o Console do Google Cloud ou a API Cloud Build, conforme descrito nesta página.

  • Gatilhos do GitHub Enterprise: esse tipo de gatilho permite invocar builds em resposta a confirmações ou solicitações de envio em uma instância do GitHub Enterprise. É possível criar repositórios do GitHub Enterprise usando o Console do Google Cloud ou a API Cloud Build.

A tabela a seguir compara os gatilhos legados do GitHub, os gatilhos do GitHub e os gatilhos do GitHub Enterprise:

Seleção de Gatilhos legados do GitHub Acionadores do GitHub Gatilhos do GitHub Enterprise
Executar versões em push para o código-fonte Yes Yes Yes
Executar builds em solicitações de envio No Yes Yes
Criar gatilho usando o Console do Google Cloud Yes Yes Yes
Criação de acionador usando a API do Cloud Build No Yes Yes
Criação de acionador usando o app GitHub para Google Cloud Build No Yes Yes
Ver o status do build no Console do Google Cloud Yes Yes Yes
Exibição do status da compilação no GitHub No Yes Yes

Compartilhamento de dados

Os gatilhos do GitHub enviam dados ao app Cloud Build do GitHub. Os dados enviados ao aplicativo ajudam a identificar gatilhos por nome e ver os resultados da versão no GitHub.

Os dados a seguir são compartilhados entre o Google Cloud e o app GitHub:

  • Código do projeto do Cloud
  • Nome do gatilho
  • registros de compilações.

Se você criou gatilhos antes de agosto de 2020, talvez o compartilhamento de dados não esteja ativado para seu projeto. É possível ativar o compartilhamento de dados para todos os gatilhos do GitHub no seu projeto clicando em Ativar na guia de compartilhamento de dados do Cloud Build.

Se as verificações de status necessárias estiverem ativadas para um repositório do GitHub, a ativação do compartilhamento de dados poderá interromper temporariamente as verificações de status. Para ajustar as configurações de verificação de status para procurar seu nome de gatilho, é possível:

  • desativar qualquer verificação necessária específica do Cloud Build no repositório do GitHub;
  • garantir que o compartilhamento de dados esteja ativado no Cloud Build;
  • executar uma nova compilação no Cloud Build que publica o status no seu repositório;
  • reativar verificações de status necessárias, selecionando o nome do gatilho.

A seguir