Criar um arquivo de acionadores

Esta página descreve as etapas para criar um arquivo YAML de acionadores no Secure Source Manager. Um arquivo de gatilhos pode ser usado para automatizar builds com base em eventos de push e solicitação de envio em um repositório do Secure Source Manager.

Para saber mais sobre os campos que podem ser incluídos em um arquivo de acionadores, leia Esquema de arquivo de acionadores.

Antes de começar

  1. Crie uma instância do Secure Source Manager.
  2. Crie um repositório do Secure Source Manager.
  3. Leia o Esquema de arquivo de acionadores para saber mais sobre os campos que podem ser incluídos em um arquivo de acionadores.

Funções exigidas

Para receber as permissões necessárias para criar um arquivo de acionadores, peça ao administrador para conceder a você os seguintes papéis do IAM:

Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

Também é possível conseguir as permissões necessárias usando personalizados papéis ou outros predefinidos papéis.

Criar um arquivo de configuração do Cloud Build

Os arquivos de acionadores do Secure Source Manager exigem que você especifique um arquivo de configuração de build para cada acionador.

Um arquivo de configuração de build contém instruções para o Cloud Build executar tarefas de acordo com as especificações que você define. Por exemplo, seu arquivo de configuração de versão pode conter instruções para criar, empacotar e enviar imagens do Docker.

Crie os arquivos de configuração do build na ramificação ou nas ramificações em que você quer criar. Para criar os arquivos de configuração do build, siga as instruções em Criar um arquivo de configuração do build.

Criar um arquivo de acionadores

\O arquivo de configuração de acionadores precisa ser criado na ramificação padrão do repositório.

Para criar um arquivo de configuração de acionadores:

  1. No repositório local ou na interface da Web do Secure Source Manager, mude para a ramificação padrão.

  2. Crie um arquivo chamado .cloudbuild/triggers.yaml.

  3. Configure o acionador no arquivo .cloudbuild/triggers.yaml:

    triggers:
- name: TRIGGER_NAME
  project: PROJECT_ID
  configFilePath: CLOUD_BUILD_CONFIG_PATH
  eventType: EVENT_TYPE
  ignoredGitRefs: IGNORED_GIT_REFS
  includedGitRefs: INCLUDED_GIT_REFS
  serviceAccount: SERVICE_ACCOUNT
  includedFiles: INCLUDED_FILES
  ignoredFiles: IGNORED_FILES
  disabled: DISABLED_BOOL
  substitutions:
    _VARIABLE_NAME: VARIABLE_VALUE
    OVERRIDE_VARIABLE_NAME: OVERRIDE_VARIABLE_VALUE

    Substitua:

    • TRIGGER_NAME por um nome para o acionador. Os nomes de acionadores só podem conter caracteres alfanuméricos e traços, e não podem começar ou terminar com um traço. Os nomes de acionadores precisam ter menos de 64 caracteres.
    • PROJECT_ID pelo Google Cloud ID do projeto em que você ativou o Cloud Build. Este campo é opcional. O padrão é o projeto do Secure Source Manager.
    • CLOUD_BUILD_CONFIG_PATH pelo caminho para o arquivo de configuração do Cloud Build que você quer usar para esse acionador. Este campo é opcional. O valor padrão é .cloudbuild/cloudbuild.yaml

    • EVENT_TYPE pelo tipo de evento que você quer acionar o build. As opções são as seguintes:

      • push para acionar o envio para as ramificações especificadas
      • pull_request para acionar uma solicitação de envio para as ramificações especificadas

      Este campo é opcional. O valor padrão é push.

    • INCLUDED_GIT_REFS com um formato de expressão regular RE2 opcional que corresponde às referências do Git que você quer acionar um build. O valor padrão é vazio. Um valor vazio indica que não há restrições.

    • IGNORED_GIT_REFS com uma expressão regular opcional usando o formato de expressão regular RE2 que corresponde às referências do Git que você não quer acionar um build. O valor padrão é vazio. Um valor vazio indica que não há restrições. O campo ignoredGitRefs é verificado antes do campo includedGitRefs. Para mais informações sobre esses campos, consulte Esquema de arquivo de acionadores.

    • SERVICE_ACCOUNT com a conta de serviço do Cloud Build a ser usada para o build no formato projects/PROJECT_ID/serviceAccounts/ACCOUNT. Substitua ACCOUNT pelo endereço de e-mail ou ID exclusivo da conta de serviço. Como prática recomendada, configure uma conta de serviço especificada pelo usuário. A conta de serviço legada do Cloud Build não pode ser usada devido às limitações.

    • INCLUDED_FILES com uma expressão regular de formato RE2 opcional que corresponde aos arquivos que você quer acionar um build.

      Se algum dos arquivos alterados não corresponder ao campo de filtro ignoredFiles e os arquivos alterados corresponderem ao campo de filtro includedFiles, um build será acionado. O valor padrão é vazio. Um valor vazio indica que não há restrições.

    • IGNORED_FILES com uma expressão regular de formato RE2 opcional que corresponde aos arquivos que você não quer acionar um build.

      Se todos os arquivos alterados em um commit corresponderem a esse campo de filtro, um build não será acionado. O valor padrão é vazio. Um valor vazio indica que não há restrições.

    • DISABLED_BOOL com true para desativar o acionador ou false para ativar o acionador. Este campo é opcional. O valor padrão é false.

    • VARIABLE_NAME com o nome de uma variável que você quer introduzir no arquivo de acionadores.

    • VARIABLE_VALUE com o valor da variável.

    • OVERRIDE_VARIABLE_NAME com o nome da variável de substituição padrão do Secure Source Manager. Para informações sobre as variáveis de substituição padrão disponíveis, consulte a seção de substituições do Esquema de arquivo de acionadores.

    • OVERRIDE_VARIABLE_VALUE com o valor que você quer substituir o valor padrão da variável de substituição padrão.

  4. Faça commit do arquivo de configuração do acionador na ramificação padrão.

    Depois que o arquivo de acionadores é confirmado, o Secure Source Manager aciona builds com base na configuração do arquivo de acionadores.

    O Secure Source Manager lê os arquivos de configuração e o SHA de commit associado ou a referência do Git dos seguintes tipos de eventos:

    • Para eventos push, o Secure Source Manager lê o SHA de commit ou a referência do Git quando o envio é concluído.
    • Para eventos pull_request, o Secure Source Manager lê o SHA de commit ou a referência do Git quando as mudanças da solicitação de envio são extraídas.

Ver o status do build

Quando um build é acionado por um evento de envio ou solicitação de envio, o commit e o status do build são exibidos na interface da Web do Secure Source Manager.

Os valores possíveis para o status do build são os seguintes:

  • sucessoSUCESSO: o build foi concluído.
  • avisoAVISO: ocorreu um problema ao tentar criar.
  • falhaFALHA: o build falhou durante a execução.

É possível impedir que commits com builds sem êxito sejam mesclados em ramificações importantes se você configurar uma regra de proteção de ramificação para exigir uma verificação de status bem-sucedida de acionadores configurados no arquivo de acionadores. Para saber mais sobre a proteção de ramificação, leia a Visão geral da proteção de ramificação.

Para conferir o status do build de um evento de envio:

  1. Na interface da Web do Secure Source Manager, navegue até o repositório.

    Se o evento de envio mais recente acionou um build, o status será exibido ao lado do SHA de commit. Para conferir detalhes sobre esse status, clique nele.

  2. Para conferir o status do build de commits anteriores, selecione Commits para conferir o histórico de commits e clique no status para conferir os detalhes.

Para conferir o status do build de um evento de solicitação de envio:

  1. Na interface da Web do Secure Source Manager, clique em Solicitações de extração.

  2. Clique na solicitação de envio que você quer conferir.

    Se os builds foram acionados pela solicitação de envio, você verá uma seção intitulada either Todas as verificações foram bem-sucedidas, ou Algumas verificações informaram avisos.

A seguir