Este é o primeiro de 4 scripts que comecei a escrever conforme indicado na arquitetura do sistema. Me senti animado! foi um passo na direção de criar a experiência "wiki" que obtém uma contribuição para o código aberto sem fazer interface com a interface do GitHub?.

O que são esses roteiros?

Estes são arquivos js que contêm algumas funções reutilizáveis ​​relacionadas, especialmente destinadas a serem usadas para interagir com as APIs do GitHub; eles são consumidos no mesmo script ou exportados para serem usados ​​para executar sua funcionalidade básica em outro lugar do projeto. Eles aceitam uma instância autenticada do Octokit de um usuário como parâmetros de outros. Esta instância é usada para executar ações/funções por meio das APIs do GitHub em nome do usuário autenticado.

A necessidade de criar um fluxo de contribuição para o código aberto sem interface com a interface do GitHub significou que tivemos que automatizar alguns processos - simulando todas as etapas que um usuário executará se contribuísse por meio da interface do GitHub, as etapas são como segue..

1. Repositório do projeto Fork
2. Criar uma filial
3. Confirmar alterações na ramificação (adicionar novo arquivo mdx no diretório src/pages/word/ para novas palavras ou editar as existentes, no nosso caso)
4. Crie uma solicitação pull (envie a palavra alterações, no nosso caso)

Uma verdade que vale a pena afirmar

Comecei a escrever este script logo após o commit inicial, este foi de fato o PR # 2, mas sofreu um golpe durante o longo intervalo do mês? tirei do projeto antes de voltar a trabalhar no recurso de dicionário básico.

O roteiro

A tarefa aqui era criar "The Fork Script" - cujo objetivo final é criar/obter um fork do repositório jargons.dev na/a partir da conta de um usuário. Deve abrigar todas as funções que farão o seguinte.

• Verifique se um Fork de jargons.dev já existe na conta de um usuário
  • Se o fork existir
    • Verifique se o Fork está sincronizado com o upstream (ou seja, atualizado com o branch principal do repositório jargons.dev); SE NÃO — Atualize o fork
  • Se NENHUM garfo for encontrado
    • Crie o fork

Compreendendo a tarefa, "mergulhei" diretamente no trabalho no roteiro.

Já estou muito acostumado com as APIs do GitHub devido ao meu consumo frequente no meu trabalho diário no Hearts ❤️... Então eu tinha a documentação do Fork do GitHub parecendo um broski para mim ?...

Os passos

• Eu criei uma função forkRepository principal que foi o principal ponto de entrada para executar a funcionalidade fork - ela leva a todos os outros lugares
• Eu adicionei as seguintes funções, que serviram principalmente como auxiliares para a óbvia função principal forkRepository
  • isRepositoryForked - esta função verifica se o repositório jargons.dev já foi bifurcado para a conta do usuário autenticado atual
  • isRepositoryForkUpdated - para verificar se o fork (se encontrado) está (em sincronização com o repositório principal) atualizado com o repositório jargons.dev principal
  • updateRepositoryFork - usado para atualizar (sincronizar) o repositório para o estado do repositório principal (head) jargons.dev
  • getBranch - é um utilitário base (necessário no momento da escrita deste script) usado para buscar detalhes de Branch/Ref para o repositório jargons.dev e o fork do usuário para usar na comparação feita no auxiliar isRepositoryForkUpdated para executar sua função principal; ele usa o endpoint de referências do GitHub.

Minha estranha suposição

Passando pela minha mente? enquanto escrevia este script, tive um pensamento que mantive depois de ler o parágrafo citado abaixo na documentação do GitHub Fork

Nota: a bifurcação de um repositório acontece de forma assíncrona. Talvez seja necessário esperar um curto período de tempo antes de poder acessar os objetos git. Se isso demorar mais de 5 minutos, entre em contato com o suporte do GitHub.

Eu entendi isso mal e presumi que só seríamos capazes de iniciar um processo de fork, seguir em frente e certamente não seríamos capazes de esperar por um objeto de resposta que retornasse os detalhes da nova bifurcação porque não sabemos quando o processo de bifurcação for concluído.

Essa suposição me forçou a não retornar nenhum dado da função forkRepository principal e eu já estava começando a pensar neste ponto - como vou fazer com que os detalhes do fork sejam processados ​​para a próxima fase do processo de contribuição!? Hmm, talvez eu use webhooks?!?

Acontece que eu estava pensando demais?, percebi mais tarde que de fato obterei detalhes de resposta para o fork e isso me levou a fazer um PR de acompanhamento para abordar o retorno dos dados necessários do objeto de resposta do fork para consumo em o processo de contribuição.

As relações públicas

Principal:

façanha: implementar script de repositório `fork` #3

Babblebey postado em 31 de dezembro de 2023

Esta solicitação pull implementa o script fork; este script deve ser usado para bifurcar programaticamente o repositório principal do projeto para uma conta de usuário; Ele abriga uma função principal e outras funções auxiliares que usa para executar algumas ações necessárias a fim de garantir uma operação eficiente do repo fork.

Alterações feitas

• Implementada a função principal forkRepository dentro do script; esta função é a principal função exportada que executa a operação principal do fork; ele aceita uma instância userOctokit (um objeto autenticado pelo usuário com permissão para agir em nome do usuário) e os detalhes do repositório do projeto, ou seja, objeto repoDetails e faz o seguinte ...
  • Verifica se o repositório do projeto já foi bifurcado para a conta do usuário usando a função auxiliar isRepositoryForked; isso retorna o fork de null
    • Se o repositório já tiver sido bifurcado, verificamos se o fork está atualizado/sincronizado com o repositório principal do projeto usando a função auxiliar isRepositoryForkUpdated; isso retorna o SHA atualizado e uma propriedade booleana isUpdated que confirma se o fork está atualizado
      • Se o fork não estiver atualizado; em seguida, realizamos a atualização sincronizando-a com o repositório principal do projeto usando a função auxiliar updateRepositoryFork
    • Se o repositório estiver atualizado/sincronizado com o repositório principal do projeto; cancelamos a operação neste momento com retorno antecipado;
  • Se o repositório do projeto não for bifurcado na conta do usuário; em seguida, iniciamos um processo de bifurcação chamando o endpoint "POST /repos/{owner}/{repo}/forks" usando a instância userOctokit. (Isso inicia o processo de bifurcação, não sabemos exatamente quando o processo é concluído?)
• Implemente as seguintes funções auxiliares consumidas na função forkRepository principal e também em outras funções auxiliares
  • updateRepositoryFork - usado para atualizar (sincronizar) o repositório para o estado do repositório principal (head)
  • isRepositoryForkUpdated - usado para verificar se um fork está (em sincronização com o repositório principal) atualizado com o repositório principal
  • getBranch - usado para buscar detalhes de uma filial/referência
  • isRepositoryForked - usado para verificar a presença de um repositório específico na lista de repositórios fork de um usuário
• Adicionado getRepoParts a /lib/utils; é uma função utilitária usada para resolver repoOwner e repoName de um nome completo do repositório.

Problema relacionado

Resolve #2

Transmissão/Captura de tela

https://github.com/babblebey/jargons.dev/assets/25631971/16221b7e-3c28-4c6c-a1f3-24d583ce7e3a

?

Ver no GitHub

talento: retornar repositório `fullname` no script fork #29

Babblebey postado em 04 de abril de 2024

Este PR é uma continuação de uma etapa que faltava na implementação inicial do script fork em #3; o script fork falhou ao retornar um repositório que pode ser usado na próxima etapa do cálculo. Isso ocorreu por causa de uma suposição estranha que tive durante a implementação inicial. ?Veja minha suposição abaixo...

Presumo que a chamada para o endpoint "POST /repos/{owner}/{repo}/forks" apenas garante o início de um processo de bifurcação, sem nos garantir nenhuma resposta. O que significa que podemos não obter exatamente um response.data após a chamada

... mas isso não era verdade, descobri que um response.data realmente vem, mas pode levar algum tempo e apenas nos casos em que o repositório que está sendo bifurcado é enorme... e no momento a bifurcação do repositório do projeto acontece em menos de 5 segundos.

Alterações feitas

• Repo de fork retornado - este é um valor de nome completo do repositório retornado da função auxiliar isRepositoryForked; Por meio deste, devolvo-o como principal valor retornado da execução da função forkRepository na condição em que o repositório já está bifurcado na conta de um usuário em execução
• Response.data.full_name retornado - este é um nome completo do repositório fork recém-criado; É um valor da resposta à chamada de endpoint "POST /repos/{owner}/{repo}/forks"; Por meio deste, devolvo-o como principal valor reajustado da execução da função forkRepository nos casos em que não havia nenhum fork já encontrado na conta do usuário em execução
• Cherry escolheu algumas alterações do nº 25 para usar aqui
  • f12f25f548a5c5836e9be7d601ed226c5269f5ee
  • 436ceea649b67812c0ec1164fde95d443ce556e0

?

Ver no GitHub