Prever a mesclagem de pull requests do Node.js com aprendizado de máquina

Neste artigo, explicarei um uso simples do aprendizado de máquina (ML) para avaliar se é possível prever com precisão a aceitação de um pull request (PR) ao criá-lo. O experimento busca gerar um programa confiável que ajude o integrador a gerenciá-los em um projeto. Como projetos grandes recebem PRs continuamente, exploramos um modelo replicável para filtrar rapidamente os indesejados.

Os trabalhos de Yu et al.¹ e Gousios et al.² propõem modelos treinados com vários repositórios para prever a aceitação até em projetos diferentes. Isso reduz a acurácia, especialmente ao treinar com projetos A e B e prever em C, cujos critérios podem ser diferentes. Nossa abordagem usa apenas dados do mesmo projeto. Prevemos PRs do Nodejs com dados disponíveis ao enviá-los para avaliar imediatamente se serão mesclados.

Construir o preditor

Precisamos criar um preditor e encontrar os parâmetros adequados. Seguimos estes passos:

1. Definir características relevantes para avaliar um PR.
2. Coletar dados das fontes do GitHub do projeto.
3. Normalizar os dados em um armazenamento persistente para modelos ML.
4. Escolher o modelo que funciona melhor com os dados.
5. Avaliar o preditor em um conjunto separado.

Definir características

No passo 1, baseamo-nos em Yu et al. e usamos estas características:

No futuro, poderíamos incluir cumprimento de requisitos de mensagens de commit, testes unitários aprovados ou número de PRs abertos. Também dados cronológicos: requisitos mudam, e um PR antigo é avaliado por padrões diferentes. Classificar dados temporais é um problema comum em ML porque critérios dependem de quando foram criados e classificados. Brownlee³ mostra uma forma de lidar com previsões.

Carga ETL

Diagrama do processo ETL

Os passos 2 e 3 usam extração, transformação e carga (ETL), que consome a API do GitHub REST (V3), tanto REST quanto GraphQL, e salva características no MongoDB. Recupera dados dos PRs pela API. Para calcular volume de mudanças e atividade, usamos um clone do repositório e um cliente git para comparar branches de origem e destino. A API GraphQL (V4) obtém informações de usuários, incluindo conexões sociais (social_conn). Permite consultas mais ricas entre entidades, como conexões de todos os autores, e reduz solicitações URL. Este código obtém dados paginados de MergedEvents de um PR para detectar se foi mesclado.

{
 repository(owner: nodejs, name: node){
   name,
   pullRequests(first: 100, states: MERGED) {
     nodes {
       id,
       url,
       timeline(last: 100) {
         nodes {
             ... on MergedEvent {
            id,
             actor {
               login
             }
             createdAt,
             url,
           }
         }
       }
     },
     pageInfo {
       hasNextPage,
       hasPreviousPage,
       endCursor,
       startCursor,
     },
     totalCount
   }
  }
}

Não pudemos usar GraphQL em todos os casos por limites menores de solicitações, que tornam a recuperação mais lenta. Chamadas complexas também foram mais lentas que equivalentes V3. Projetamos ETL para ser retomado e reiniciado, pois pode levar horas. Dividimos nestas tarefas:

Tarefas ETL para carregar e normalizar dados

Construção e avaliação do preditor

Sobreajuste de precedentes eleitorais (fonte: XKCD)

Com os dados prontos, os passos 4 e 5 usam scikit-learn. Para evitar sobreajuste, dividimos em treinamento e validação: 90% dos PRs para treinar e 10% para validar. Fazemos validação cruzada dividindo o treinamento em 10 grupos com k-fold. Testamos estes preditores:

• Naive Bayes (Bernoulli e gaussiano)
• Árvores de decisão
• K vizinhos mais próximos
• Análise discriminante linear
• Regressão logística
• Perceptrons multicamadas
• Centroides mais próximos
• Análise discriminante quadrática
• Regressão Ridge
• Máquinas de vetores de suporte (SVC), com suporte C e lineares
• Descida de gradiente estocástico (SGD)
• Algoritmos passivo-agressivos

Diagrama de validação k-fold com 4 grupos (fonte: Wikipedia)

Coletamos 10,200 PRs do repositório nodejs entre novembro de 2014 e novembro de 2017. Os dados brutos tinham esta forma. Cerca de 76% dos MRs recuperados foram mesclados; é um conjunto considerável para treinar a maioria dos preditores.

Testamos 21 classificadores e obtivemos acurácia de 77% a 88% no treinamento. Escolhemos SVC com suporte C, com média de 87% em 10 validações cruzadas. É bom para treinamento, mas a avaliação real usa dados de teste. Ali, alcançou precisão um pouco menor, de 78%, ainda aceitável.

Métricas de precisão sobre dados de teste

Conclusões e melhorias futuras

Os experimentos mostram que podemos prever MRs com acurácia e aliviar a carga dos integradores diante de grandes filas. Dados temporais exigem tratamento especial: critérios mudam, e talvez convenha filtrar MRs antigos. Mais características melhorarão as previsões. Extrair dados do GitHub pode demorar e exige lidar com desconexões e limites da API para recuperar o processo. Cada projeto também tem mecanismos diferentes de mesclagem, às vezes sem a função “merge” do GitHub, e pode exigir CI para aceitar um MR. Isso precisa ser considerado. Não há solução universal, mas com ferramentas adequadas pode-se criar uma aplicação preditora para cada projeto com MRs suficientes. O código está em https://github.com/sophilabs/pullreq-ml.

Referências