Automatize builds em resposta a eventos do Pub/Sub

Com os gatilhos do Cloud Build Pub/Sub, é possível executar builds em resposta a eventos do Google Cloud publicados no Pub/Sub. Você pode usar informações de um evento do Pub/Sub para parametrizar seu build e decidir se ele será executado em resposta ao evento. Os gatilhos do Pub/Sub podem ser configurados para detectar qualquer tópico do Pub/Sub.

Nesta página, explicamos como criar um gatilho do Pub/Sub para automatizar builds em resposta a eventos no Artifact Registry, Container Registry e Cloud Storage.

Antes de começar

  • Ative a API Cloud Build.

    Ative a API

  • Verifique se o código-fonte contém um arquivo de configuração do build ou um Dockerfile no repositório.

  • Para usar os comandos do gcloud nesta página, instale a CLI do Google Cloud.

Como criar um gatilho de compilação que responde a eventos do Artifact Registry

É possível criar um gatilho do Pub/Sub que responde a eventos do Artifact Registry, como quando imagens são enviadas, excluídas ou tags são incluídas. Esta seção mostra como criar um gatilho do Pub/Sub que invoca um build quando uma nova tag é enviada para uma imagem existente. Se você não estiver familiarizado com o Artifact Registry, consulte a visão geral do Artifact Registry.

Console

Para criar um gatilho que detecta uma nova tag enviada para uma imagem existente no Artifact Registry usando o Console do Google Cloud:

  1. Acesse a página Gatilhos:

    Abrir a página Acionadores

  2. Selecione seu projeto na parte superior da página e clique em Abrir.

  3. Clique em Criar gatilho.

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

    • Nome: insira um nome para o gatilho.

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

      • 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 particular para executar o build. 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 o build na mesma região do gatilho.

    • Descrição (opcional): insira uma descrição para o gatilho.

    • Evento: selecione Mensagem do Pub/Sub como o evento para invocar o gatilho.

    • Assinatura: selecione o tópico do Pub/Sub que gostaria de assinar como o evento do gatilho. Você pode ver todos os tópicos atuais no projeto no menu suspenso.

    • Origem: selecione o repositório a ser criado quando o gatilho for executado.

    • Revisão: selecione a ramificação ou a tag a ser criada quando o gatilho for executado.

      • Ramificação: digite o nome da ramificação em que o build será invocado.
      • Tag: insira o nome da tag para invocar seu build.

    • Configuração: selecione o arquivo de configuração do build (localizado no seu repositório remoto) ou crie um arquivo de configuração do build inline para usar no build.

      • Type: selecione o tipo de configuração a ser usado para o build.
        • 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, o diretório Dockerfile , ou o diretório buildpacks. Se o tipo de configuração do build for um Dockerfile ou um buildpack, você precisará fornecer um nome para a imagem resultante e, opcionalmente, um tempo limite para o seu build. Depois de fornecer o nome da imagem Dockerfile ou do buildpack, você verá uma visualização do comando docker build ou pack que seu build executará.
        • Variáveis de ambiente de pacote (opcional): se você tiver selecionado buildpacks como tipo de configuração, clique em Adicionar variável de ambiente de pacote para especificar os valores e variáveis de ambiente do buildpack. Para saber mais sobre as variáveis de ambiente de buildpack, consulte Variáveis de ambiente.

        • 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 gravar seu 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.

    • Substituições (opcional): se você selecionou o arquivo de configuração do build como opção de configuração do build, é possível optar por definir variáveis de substituição específicas do gatilho usando este campo.

      No exemplo a seguir, queremos obter o nome da tag de imagem do payload e da ação associada ao evento gcr. Para tal, crie variáveis de substituição usando vinculações de payload.

      Especifique as seguintes variáveis e valores abaixo:

      Nome da variável Valor da variável
      _IMAGE_TAG $(body.message.data.tag)
      _ACTION $(body.message.data.action)

      body.message faz referência ao PubSubMessage publicado por editores e consumido por assinantes. Para ver mais exemplos do payload de notificação do Pub/Sub, consulte Exemplos de notificação.

    • Filtros (opcional): é possível criar filtros em um gatilho que determinam se o gatilho executará ou não um build em resposta ao payload de entrada especificando filtros em variáveis de substituição. A expressão de filtro precisa ser avaliada como true para que um build seja executado.

      Recomendamos usar a filtragem ao configurar gatilhos do Pub/Sub em tópicos com várias mensagens. Os filtros podem ser usados para controlar com precisão os builds que são executados em resposta às mensagens recebidas do Pub/Sub. Para saber os riscos associados à configuração de um gatilho sem filtros, consulte Riscos associados a um gatilho não filtrado.

      No exemplo a seguir, queremos que o gatilho execute um build se uma nova tag for enviada para uma imagem existente. Usamos operadores de condição de filtro para verificar se a variável _IMAGE_TAG corresponde a um nome de tag existente e se a variável _ACTION corresponde a INSERT para procurar dados recém-adicionados.

      Especifique o seguinte como seus filtros:

      • _IMAGE_TAG != ""
      • _ACTION == INSERT

      A sintaxe de filtragem nos gatilhos do Pub/Sub usa a Common Expression Language (CEL) para a avaliação de expressões. Para saber mais sobre CEL, consulte o repositório cel-spec. Para ver mais exemplos de sintaxe de filtragem que podem ser aplicados aos seus gatilhos do Pub/Sub, consulte Como usar a CEL para filtrar eventos do build.

  1. Clique em Criar para criar seu gatilho de compilação.
    2. .

gcloud

Para criar um gatilho que detecte uma nova tag enviada a uma imagem existente no Artifact Registry usando os comandos gcloud:

  1. Abra uma janela de terminal.

  2. Execute o comando gcloud alpha para criar um gatilho de compilação no projeto. No exemplo abaixo, o gatilho está configurado para responder a builds com uma correspondência de tag prod e uma correspondência de ação INSERT com base no payload especificado, conforme definido pela variável de substituição, _IMAGE_TAG.

     gcloud alpha builds triggers create pubsub \
   --name=TRIGGER_NAME \
   --topic=projects/PROJECT_ID/topics/TOPIC_NAME \
   --build-config=BUILD_CONFIG \ # or --inline-config=INLINE_BUILD_CONFIG
   --substitutions=\
     _IMAGE_TAG_='$(body.message.data.tag)'
     _ACTION='$(body.message.data.action)'
   --filter='_IMAGE_TAG == "" && _ACTION == "INSERT"'
   --repo=REPO_NAME
   --tag=TAG_NAME  # or --branch=BRANCH_NAME

    Em que:

    • TRIGGER_NAME é o nome do gatilho.
    • PROJECT_ID é o ID do projeto do Cloud.
    • TOPIC_NAME é o nome do tópico do Pub/Sub que você assinou.
    • BUILD_CONFIG é o caminho para seu arquivo de configuração do build.
    • INLINE_BUILD_CONFIG é o caminho para o arquivo de configuração do build inline.
    • REPO_NAME é o nome do repositório de origem em que o build é invocado.
    • TAG_NAME é o nome da tag caso você queira definir o gatilho para criar uma tag.
    • BRANCH_NAME é o nome da ramificação, caso você queira definir o gatilho para criar em uma ramificação.

Como criar um gatilho de compilação que responde a eventos do Container Registry

É possível criar um gatilho do Pub/Sub que responde a eventos do Container Registry, como quando imagens são enviadas, excluídas ou tags são incluídas. Esta seção mostra como criar um gatilho do Pub/Sub que invoca um build quando uma imagem corresponde a uma tag configurada por um filtro personalizado. Se você não estiver familiarizado com o Container Registry, consulte o Guia de início rápido do Container Registry para saber como enviar e receber imagens com tags.

Console

Para criar um gatilho que detecta um envio de imagem no Container Registry e faz a correspondência com base no nome de uma tag usando o Console do Google Cloud:

  1. Acesse a página Gatilhos:

    Abrir a página Acionadores

  2. Selecione seu projeto na parte superior da página e clique em Abrir.

  3. Clique em Criar gatilho.

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

    • Nome: insira um nome para o gatilho.

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

      • 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 particular para executar o build. 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 o build na mesma região do gatilho.

    • Descrição (opcional): insira uma descrição para o gatilho.

    • Evento: selecione Mensagem do Pub/Sub como o evento para invocar o gatilho.

    • Assinatura: selecione o tópico do Pub/Sub que gostaria de assinar como o evento do gatilho. Você pode ver todos os tópicos atuais no projeto no menu suspenso.

    • Origem: selecione o repositório a ser criado quando o gatilho for executado.

    • Revisão: selecione a ramificação ou a tag a ser criada quando o gatilho for executado.

      • Ramificação: digite o nome da ramificação em que o build será invocado.
      • Tag: insira o nome da tag para invocar seu build.

    • Configuração: selecione o arquivo de configuração do build (localizado no seu repositório remoto) ou crie um arquivo de configuração do build inline para usar no build.

      • Type: selecione o tipo de configuração a ser usado para o build.
        • 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, o diretório Dockerfile , ou o diretório buildpacks. Se o tipo de configuração do build for um Dockerfile ou um buildpack, você precisará fornecer um nome para a imagem resultante e, opcionalmente, um tempo limite para o seu build. Depois de fornecer o nome da imagem Dockerfile ou do buildpack, você verá uma visualização do comando docker build ou pack que seu build executará.
        • Variáveis de ambiente de pacote (opcional): se você tiver selecionado buildpacks como tipo de configuração, clique em Adicionar variável de ambiente de pacote para especificar os valores e variáveis de ambiente do buildpack. Para saber mais sobre as variáveis de ambiente de buildpack, consulte Variáveis de ambiente.

        • 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 gravar seu 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.

    • Substituições (opcional): se você selecionou o arquivo de configuração do build como opção de configuração do build, é possível optar por definir variáveis de substituição específicas do gatilho usando este campo.

      No exemplo a seguir, queremos obter o nome da tag de imagem do payload e da ação associada ao evento gcr. Para tal, crie variáveis de substituição usando vinculações de payload.

      Especifique as seguintes variáveis e valores abaixo:

      Nome da variável Valor da variável
      _IMAGE_TAG $(body.message.data.tag)
      _ACTION $(body.message.data.action)

      body.message faz referência ao PubSubMessage publicado por editores e consumido por assinantes. Para ver mais exemplos do payload de notificação do Pub/Sub, consulte Exemplos de notificação.

    • Filtros (opcional): é possível criar filtros em um gatilho que determinam se o gatilho executará ou não um build em resposta ao payload de entrada especificando filtros em variáveis de substituição. A expressão de filtro precisa ser avaliada como true para que um build seja executado.

      Recomendamos usar a filtragem ao configurar gatilhos do Pub/Sub em tópicos com várias mensagens. Os filtros podem ser usados para controlar com precisão os builds que são executados em resposta às mensagens recebidas do Pub/Sub. Para saber os riscos associados à configuração de um gatilho sem filtros, consulte Riscos associados a um gatilho não filtrado.

      No exemplo a seguir, queremos que o gatilho execute um build se o nome da variável de tag _IMAGE_TAG corresponder a um nome de tag específico, como prod. Você pode especificar o operador da condição de filtro como "==" para correspondência exata. Também é possível verificar a ação associada ao seu evento gcr. Por exemplo, talvez você queira especificar _ACTION como INSERT para procurar dados recém-adicionados.

      Especifique o seguinte como seus filtros:

      • _IMAGE_TAG == prod
      • _ACTION == INSERT

      A sintaxe de filtragem nos gatilhos do Pub/Sub usa a Common Expression Language (CEL) para a avaliação de expressões. Para saber mais sobre CEL, consulte o repositório cel-spec. Para ver mais exemplos de sintaxe de filtragem que podem ser aplicados aos seus gatilhos do Pub/Sub, consulte Como filtrar builds.

  1. Clique em Criar para criar seu gatilho de compilação.
    2. .

gcloud

Para criar um gatilho que detecta um envio de imagem no Container Registry e faz a correspondência com base em um nome de tag usando comandos gcloud:

  1. Abra uma janela de terminal.

  2. Execute o comando gcloud alpha para criar um gatilho de compilação no projeto. No exemplo abaixo, o gatilho está configurado para responder a builds com uma correspondência de tag prod e uma correspondência de ação INSERT com base no payload especificado, conforme definido pela variável de substituição, _IMAGE_TAG.

     gcloud alpha builds triggers create pubsub \
   --name=TRIGGER_NAME \
   --topic=projects/PROJECT_ID/topics/TOPIC_NAME \
   --build-config=BUILD_CONFIG \ # or --inline-config=INLINE_BUILD_CONFIG
   --substitutions=\
     _IMAGE_TAG_='$(body.message.data.tag)'
     _ACTION='$(body.message.data.action)'
   --filter='_IMAGE_TAG == "prod" && _ACTION == "INSERT"'
   --repo=REPO_NAME
   --tag=TAG_NAME  # or --branch=BRANCH_NAME

    Em que:

    • TRIGGER_NAME é o nome do gatilho.
    • PROJECT_ID é o ID do projeto do Cloud.
    • TOPIC_NAME é o nome do tópico do Pub/Sub que você assinou.
    • BUILD_CONFIG é o caminho para seu arquivo de configuração do build.
    • INLINE_BUILD_CONFIG é o caminho para o arquivo de configuração do build inline.
    • REPO_NAME é o nome do repositório de origem em que o build é invocado.
    • TAG_NAME é o nome da tag caso você queira definir o gatilho para criar uma tag.
    • BRANCH_NAME é o nome da ramificação, caso você queira definir o gatilho para criar em uma ramificação.

Como criar um gatilho de compilação que responde a eventos do Cloud Storage

É possível criar um gatilho do Pub/Sub que responde a eventos do Cloud Storage, como quando um novo binário é enviado para um bucket de armazenamento atual. Esta seção mostra como criar um gatilho do Pub/Sub que responde com um build ao implantar um novo binário em um bucket enviado. Se você não estiver familiarizado com o Cloud Storage, consulte os Guias de início rápido.

Console

Para criar um gatilho que detecta eventos do Cloud Storage usando o Console do Google Cloud:

  1. Acesse a página Gatilhos:

    Abrir a página Acionadores

  2. Selecione seu projeto na parte superior da página e clique em Abrir.

  3. Clique em Criar gatilho.

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

    • Nome: insira um nome para o gatilho.

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

      • 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 particular para executar o build. 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 o build na mesma região do gatilho.

    • Descrição (opcional): insira uma descrição para o gatilho.

    • Evento: selecione Mensagem do Pub/Sub como o evento para invocar o gatilho.

    • Assinatura: selecione o tópico do Pub/Sub que gostaria de assinar como o evento do gatilho. Você pode ver todos os tópicos atuais no projeto no menu suspenso.

    • Origem: selecione o repositório a ser criado quando o gatilho for executado.

    • Revisão: selecione a ramificação ou a tag a ser criada quando o gatilho for executado.

      • Ramificação: digite o nome da ramificação em que o build será invocado.
      • Tag: insira o nome da tag para invocar seu build.

    • Configuração: selecione o arquivo de configuração do build (localizado no seu repositório remoto) ou crie um arquivo de configuração do build inline para usar no build.

      • Type: selecione o tipo de configuração a ser usado para o build.
        • 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, o diretório Dockerfile , ou o diretório buildpacks. Se o tipo de configuração do build for um Dockerfile ou um buildpack, você precisará fornecer um nome para a imagem resultante e, opcionalmente, um tempo limite para o seu build. Depois de fornecer o nome da imagem Dockerfile ou do buildpack, você verá uma visualização do comando docker build ou pack que seu build executará.
        • Variáveis de ambiente de pacote (opcional): se você tiver selecionado buildpacks como tipo de configuração, clique em Adicionar variável de ambiente de pacote para especificar os valores e variáveis de ambiente do buildpack. Para saber mais sobre as variáveis de ambiente de buildpack, consulte Variáveis de ambiente.

        • 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 gravar seu 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.

    • Substituições (opcional): se você selecionou o arquivo de configuração do build como opção de configuração do build, é possível optar por definir variáveis de substituição específicas do gatilho usando este campo.

      Neste exemplo, queremos observar a implantação de um novo binário quando ele for enviado para um bucket. Para obter esses dados, podemos criar variáveis de substituição usando vinculações de payload.

      Especifique as seguintes variáveis e valores abaixo:

      Nome da variável Valor da variável
      _EVENT_TYPE $(body.message.attributes.eventType)
      _BUCKET_ID $(body.message.attributes.bucketId)
      _OBJECT_ID $(body.message.attributes.objectId)

      body.message faz referência ao PubSubMessage publicado por editores e consumido por assinantes. Para ver mais exemplos do payload de notificação do Pub/Sub, consulte Exemplos de notificação.

    • Filtros (opcional): é possível criar filtros em um gatilho que determinam se o gatilho executará ou não um build em resposta ao payload de entrada especificando filtros em variáveis de substituição. A expressão de filtro precisa ser avaliada como true para que um build seja executado.

      Recomendamos usar a filtragem ao configurar gatilhos do Pub/Sub em tópicos com várias mensagens. Os filtros podem ser usados para controlar com precisão os builds que são executados em resposta às mensagens recebidas do Pub/Sub. Para saber os riscos associados à configuração de um gatilho sem filtros, consulte Riscos associados a um gatilho não filtrado.

      Como queremos que o gatilho execute um build se o novo binário tiver sido implantado em um bucket específico, podemos usar o operador "==" para verificar correspondências exatas. Você também pode usar a palavra-chave "corresponde" se quiser fazer a correspondência por expressão regular.

      Especifique o seguinte como seus filtros:

      • _EVENT_TYPE == OBJECT_FINALIZE
      • _OBJECT_ID corresponde ^<object-id>$
      • _BUCKET_ID corresponde ^<bucket-id>$
  1. Clique em Criar para criar seu gatilho de compilação.
    2. .

gcloud

Para criar um gatilho de compilação que detecte eventos de build com um tipo de evento específico no Cloud Storage:

  1. Abra uma janela de terminal.

  2. Execute o comando gcloud alpha para criar um gatilho de compilação no projeto. No exemplo abaixo, o gatilho está configurado para responder a builds com um evento do Cloud Storage associado a um novo binário enviado a um bucket de armazenamento:

     gcloud alpha builds triggers create pubsub \
   --name=TRIGGER_NAME \
   --topic=projects/PROJECT_ID/topics/TOPIC_NAME \
   --build-config=BUILD_CONFIG \ # or --inline-config=INLINE_BUILD_CONFIG
   --substitutions=\
     _EVENT_TYPE='$(body.message.attributes.eventType)'
     _BUCKET_ID='$(body.message.attributes.bucketId)'
     _OBJECT_ID='$(body.message.attributes.objectId)'
   --filter='_EVENT_TYPE == "OBJECT_FINALIZE" && _OBJECT_ID.matches("<object-id>") && _BUCKET_ID.matches("<bucket-id>")'
   --repo=REPO_NAME
   --tag=TAG_NAME  # or --branch=BRANCH_NAME

    Em que:

    • TRIGGER_NAME é o nome do gatilho.
    • PROJECT_ID é o ID do projeto do Cloud.
    • TOPIC_NAME é o nome do tópico do Pub/Sub que você assinou.
    • BUILD_CONFIG é o caminho para seu arquivo de configuração do build.
    • INLINE_BUILD_CONFIG é o caminho para o arquivo de configuração do build inline.
    • REPO_NAME é o nome do repositório de origem em que o build é invocado.
    • TAG_NAME é o nome da tag caso você queira definir o gatilho para criar uma tag.
    • BRANCH_NAME é o nome da ramificação, caso você queira definir o gatilho para criar em uma ramificação.

Riscos associados a um gatilho não filtrado

Se você não tiver configurado filtros no gatilho do Pub/Sub, ele poderá acabar invocando um número infinito de builds se o gatilho modificar um artefato ou objeto que publica acidentalmente uma nova mensagem no tópico que está detectando. Por exemplo, seu gatilho poderá invocar um número infinito de builds se o gatilho:

  • Aponta para um tópico gcr.
  • Cria qualquer imagem ou tag em gcr.
  • Aponta para um tópico gcs de um objeto específico no bucket e modifica esse objeto.

Se você encontrar um loop infinito, poderá excluir o gatilho ou atualizá-lo para apontar para um tópico separado para evitar cobranças adicionais por cada build que você invocar.

Como usar a CEL para filtrar eventos de build

O Cloud Build usa a CEL com a variável build nos campos listados no recurso Build para acessar os campos associados ao evento de build, como o ID do gatilho, a lista de imagens ou os valores de substituição. Use a string filter para filtrar eventos de build no arquivo de configuração do build usando qualquer campo listado no recurso Build. Para encontrar a sintaxe exata associada ao seu campo, consulte o arquivo cloudbuild.proto.

Como filtrar por ID do gatilho

Para filtrar por ID de gatilho, especifique o valor do ID do gatilho no campo filter usando build.build_trigger_id, em que trigger-id é o ID do gatilho como uma string:

filter: build.build_trigger_id == trigger-id

Como filtrar por status

Para filtrar por status, especifique o status do build que você quer filtrar no campo filter usando build.status.

O exemplo a seguir mostra como filtrar eventos de build com um status SUCCESS usando o campo filter:

filter: build.status == Build.Status.SUCCESS

Também é possível filtrar builds com status variados. O exemplo a seguir mostra como filtrar eventos de build com um status SUCCESS, FAILURE ou TIMEOUT usando o campo filter:

filter: build.status in [Build.Status.SUCCESS, Build.Status.FAILURE, Build.Status.TIMEOUT]

Para ver valores de status adicionais pelos quais você pode filtrar, consulte Status na referência do recurso do Build.

Como filtrar por tag

Para filtrar por tag, especifique o valor da tag no campo filter usando build.tags, em que tag-name é o nome da tag:

filter: tag-name in build.tags

É possível filtrar com base no número de tags especificadas no evento de build usando size. No exemplo a seguir, o campo filter filtra eventos de build que têm exatamente duas tags especificadas, uma delas como v1:

filter: size(build.tags) == 2 && "v1" in build.tags

Como filtrar por imagens

Para filtrar por imagens, especifique o valor da imagem no campo filter usando build.images, em que image-name é o nome completo da imagem conforme listado no Container Registry, como gcr.io/example/image-one:

filter: image-name in build.images

No exemplo a seguir, o filter filtra eventos de build com gcr.io/example/image-one ou gcr.io/example/image-two especificados como nomes de imagem:

filter: "gcr.io/example/image-one" in build.images || "gcr.io/example/image-two" in build.images

Como filtrar por tempo

É possível filtrar eventos de build com base no tempo de criação, horário de início ou horário de término de um build especificando uma das seguintes opções no campo filter: build.create_time, build.start_time ou build.finish_time.

No exemplo a seguir, o campo filter usa timestamp para filtrar eventos de build com um horário de solicitação para criar o build em 20 de julho de 2020, às 6h:

filter: build.create_time == timestamp("2020-07-20:T06:00:00Z")

Também é possível filtrar eventos de build por comparações de tempo. No exemplo a seguir, o campo filter usa timestamp para filtrar eventos de versão com um horário de início entre 6 de julho de 2020, às 6h, e 30 de julho de 2020, às 6h.

filter: timestamp("2020-07-20:T06:00:00Z") >= build.start_time && build.start_time <= timestamp("2020-07-30:T06:00:00Z")

Para saber mais sobre como os fusos horários são expressos em CEL, consulte a definição de linguagem para fusos horários.

Para filtrar por duração de um build, use duration para comparar carimbos de data/hora. No exemplo a seguir, o campo filter usa duration para filtrar eventos de build com um build executado por pelo menos cinco minutos:

filter: build.finish_time - build.start_time >= duration("5m")

Como filtrar por substituição

É possível filtrar por substituição especificando a variável de substituição no campo filter usando build.substitutions. No exemplo a seguir, o campo filter lista versões que contêm a variável de substituição substitution-variable e verifica se o substitution-variable corresponde ao substitution-value especificado:

filter: build.substitutions[substitution-variable] == substitution-value

Em que:

  • substitution-variable é o nome da variável de substituição.
  • substitution-value é o nome do valor de substituição.

Também é possível filtrar por padrão os valores das variáveis de substituição. No exemplo a seguir, o campo filter lista os builds que têm o nome da ramificação master e os builds que têm o nome de repositório github.com/user/my-example-repo. As variáveis de substituição padrão BRANCH_NAME e REPO_NAME são transmitidas como chaves para o build.substitutions:

filter: build.substitutions["BRANCH_NAME"] == "master" && build.substitutions["REPO_NAME"] == "github.com/user/my-example-repo"

Se você quiser filtrar strings usando expressões regulares, use a função integrada matches. No exemplo abaixo, o campo filter filtra as criações com status FALHA ou TEMPO LIMITE e também tem uma variável de substituição de versão TAG_NAME com um valor correspondente à expressão regular v{DIGIT}.{DIGIT}.{3 DIGITS})

filter: build.status in [Build.Status.FAILURE, Build.Status.TIMEOUT] && build.substitutions["TAG_NAME"].matches("^v\\d{1}\\.\\d{1}\\.\\d{3}$")`

Para ver uma lista de valores de substituição padrão, consulte Como usar substituições padrão.

A seguir