Existe uma maneira de separar os webhooks do GitHub em três categorias: mestre, pull-request e qualquer outra coisa?

9

O que estou tentando realizar é a configuração de trabalho a seguir Jenkins ( link ):

  1. Ter um conjunto de <project>-master jobs que são acionados por

    • Um push para o ramo principal desse projeto específico.
    • manualmente, clicando em "Construir agora"
    • Por um script usando a API REST.

    Eu consegui isso especificando o refspec apropriado, adicionei o webhook do GitHub, etc. Foi muito simples.

  2. Ter um conjunto de <project>-pr jobs que são acionados por

    • Uma criação de PR do GitHub.
    • Um comentário para o PR que aciona o GitHub Pull Request Builder.
    • Um push para o branch que foi usado para PR específico.

    Eu fiz Jenkins fazer os dois primeiros. Mas eu não encontrei nenhuma maneira de fazer o item # 3 desta lista porque os plugins do GitHub não podem encontrar facilmente se o push é para um ramo de RP ou não. Alguma idéia de como isso pode ser feito?

  3. Tenha um conjunto de <project>-branch jobs que são acionados por QUALQUER push para QUALQUER ramificação. O problema é que eu quero excluir pushs para master e branches que são usados para PRs. Eu procurei na Internet por uma possível solução por dias e não consegui nada, então qualquer sugestão será muito apreciada.

por DejanLekic 24.02.2016 в 12:15
fonte

1 resposta

2
  1. Para um trabalho ser acionado somente por alterações no ramo principal, não é necessário mexer com o webook do github. Você pode simplesmente usar a ramificação git plugins para especificar que esta tarefa só deve ser executada para a ramificação principal.
  2. Para configurar um trabalho para usar o plug-in Github PUll Builder como recomendado, ele só será acionado para um PR, para as três condições listadas.

  3. o mais difícil Até onde eu sei, não existe uma maneira fácil de os jenkins saberem se um branch tem um pedido de pull ou não, já que os pull requests são específicos para o github, e a detecção de branch do Jenkins está apenas usando git.

No entanto, pela minha experiência, para esta terceira opção, configurei um trabalho <project>-feature e configurei-o para corresponder a qualquer ramificação prefixada com f/ . Dessa forma, se um desenvolvedor quisesse que os testes fossem executados automaticamente em sua ramificação, mas não quisesse abrir uma solicitação de recebimento, ele poderia criar o branch como f/add_a_thing e disparar automaticamente os testes em push. Para que isso funcione, eu definiria o especificador de ramificação como f/* na configuração do trabalho.

Como alternativa, o plugin git permite um parâmetro de expressão regular para o especificador de ramificação. Você pode usar uma expressão regular para ignorar especificamente o ramo mestre. No entanto, a única maneira de ignorar as ramificações solicitadas é fazer com que seus desenvolvedores usem um padrão de nomenclatura, como pr/add_a_thing , para identificar que essa ramificação terá uma solicitação de recebimento com ela.

    
por Jeff 29.02.2016 / 14:34
fonte