Criar um arquivo de acionadores

Nesta página, descrevemos as etapas para criar um arquivo YAML de acionadores no Secure Source Manager. Um arquivo de acionadores pode ser usado para automatizar builds com base em eventos de envio 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 gatilhos, leia Esquema do arquivo de gatilhos.

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 do 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 gatilhos, 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 papéis personalizados ou outros papéis predefinidos.

Criar um arquivo de configuração do Cloud Build

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

Um arquivo desse tipo 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 de build 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 gatilhos precisa ser criado na ramificação padrão do repositório.

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

  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 com um nome para o gatilho. Os nomes de gatilho podem conter apenas caracteres alfanuméricos e traços, e não podem começar ou terminar com um traço. É preciso que os nomes dos gatilhos tenham menos de 64 caracteres.
    • PROJECT_ID pelo ID do projeto em que você ativou o Cloud Build. Google Cloud Este campo é opcional. O padrão é o projeto do Secure Source Manager.
    • CLOUD_BUILD_CONFIG_PATH com o caminho para o arquivo de configuração do Cloud Build que você quer usar para esse gatilho. Este campo é opcional. O valor padrão é .cloudbuild/cloudbuild.yaml

    • EVENT_TYPE com o tipo de evento que você quer usar para acionar o build. As opções são:

      • push para acionar o envio para os branches especificados
      • 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 usar para 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 do 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 dela.

    • INCLUDED_FILES com uma expressão regular opcional no formato RE2 que corresponda aos arquivos que você quer usar para acionar um build.

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

    • IGNORED_FILES com uma expressão regular opcional no formato RE2 que corresponda aos arquivos que você não quer usar para acionar um build.

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

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

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

    • 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 usar para 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 gatilhos é confirmado, o Secure Source Manager aciona builds com base na configuração do arquivo de gatilhos.

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

    • Para eventos push, o Secure Source Manager lê o SHA do commit ou a referência do Git quando o push é 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 solicitação push ou pull, o status do commit e do build é exibido na interface da Web do Secure Source Manager.

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

  • sucessoSUCCESS: o build foi concluído com sucesso.
  • avisoAVISO: ocorreu um problema ao tentar criar.
  • falhaFAILURE: a criação 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ções, leia a Visão geral da proteção de ramificações.

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

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

    Se o evento de push mais recente tiver acionado um build, o status será exibido ao lado do SHA do commit. Para ver detalhes sobre esse status, clique nele.

  2. Para conferir o status de builds de commits anteriores, selecione Commits para ver 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 envio.

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

    Se os builds foram acionados pela solicitação de envio, você vai ver uma seção intitulada Todas as verificações foram concluídas ou Algumas verificações informaram avisos.

A seguir