Il s'agit du premier des 4 scripts que j'ai décidé d'écrire comme indiqué dans l'architecture du système. Je me sentais pompé ! c'était un pas dans la direction de la création d'une expérience « wiki » qui permet de contribuer à l'Open source sans s'interfacer avec l'interface utilisateur de GitHub ?.

Quels sont ces scripts ?

Il s'agit de fichiers js qui contiennent certaines fonctions réutilisables associées, particulièrement destinées à être utilisées pour interagir avec les API GitHub ; ils sont soit consommés dans le même script, soit exportés pour être utilisés pour exécuter leurs fonctionnalités de base ailleurs dans le projet. Ils acceptent une instance Octokit authentifiée d'un utilisateur comme paramètres parmi les autres, cette instance est utilisée pour effectuer des actions/fonctions via les API GitHub au nom de l'utilisateur authentifié.

La nécessité de créer un flux de contribution à l'Open source sans interface avec l'interface utilisateur de GitHub signifiait que nous devions automatiser certains processus - en simulant toutes les étapes qu'un utilisateur suivrait s'il devait contribuer via l'interface utilisateur de GitHub, les étapes sont les suivantes suit..

1. Repo du projet Fork
2. Créer une succursale
3. Valider les modifications apportées à la branche (ajouter un nouveau fichier mdx dans le répertoire src/pages/word/ pour un nouveau mot ou modifier ceux existants, dans notre cas)
4. Créer une Pull Request (Soumettre les modifications de mots, dans notre cas)

Une vérité qui mérite d'être déclarée

J'ai commencé à écrire ce script juste après le commit initial, c'était en fait le PR #2, mais il a pris un coup pendant le long mois de pause ? J'ai tiré des leçons du projet avant de me remettre au travail sur la fonctionnalité de dictionnaire de base.

Le scénario

La tâche ici était de créer "The Fork Script" - dont l'objectif final est de créer/obtenir un fork du dépôt jargons.dev sur/à partir du compte d'un utilisateur. Il devrait héberger toutes les fonctions qui feront ce qui suit.

• Vérifier si un Fork de jargons.dev existe déjà sur le compte d'un utilisateur
  • Si Fork existe
    • Vérifiez si le Fork est synchronisé avec l'amont (c'est-à-dire à jour avec la branche principale du repo jargons.dev) ; SI NON – Mettre à jour le fork
  • Si AUCUNE fourchette n'est trouvée
    • Créer la fourchette

Comprenant la mission, je me suis « plongé » directement dans le travail sur le script.

Je suis déjà très habitué aux API GitHub du fait de ma consommation fréquente dans mon travail quotidien sur Hearts ❤️... J'avais donc la documentation Fork de GitHub qui me paraissait un broski ?...

Les étapes

• J'ai créé une fonction forkRepository principale qui était le principal point d'entrée pour exécuter la fonctionnalité fork - elle mène partout ailleurs
• J'ai ajouté les fonctions suivantes, qui servaient principalement d'aide à la fonction principale évidente de forkRepository
  • isRepositoryForked - cette fonction vérifie si le référentiel jargons.dev est déjà bifurqué vers le compte de l'utilisateur authentifié actuel
  • isRepositoryForkUpdated - pour vérifier si le fork (s'il est trouvé) est (en synchronisation avec le dépôt principal) à jour avec le dépôt principal jargons.dev
  • updateRepositoryFork - utilisé pour mettre à jour le référentiel (Sync) vers l'état du référentiel principal (head) jargons.dev
  • getBranch - est un utilitaire de base (requis au moment de l'écriture de ce script) utilisé pour récupérer les détails de Branch/Ref pour le dépôt jargons.dev et le fork de l'utilisateur à utiliser dans la comparaison effectuée dans l'assistant isRepositoryForkUpdated pour remplir sa fonction principale ; il utilise le point de terminaison des références GitHub.

Mon hypothèse étrange

Qui me traverse l'esprit ? pendant que j'écrivais ce script, c'était une pensée à laquelle je me suis accroché après avoir lu le paragraphe cité ci-dessous sur la documentation de GitHub Fork

Remarque : la création d'un référentiel se produit de manière asynchrone. Vous devrez peut-être attendre un court laps de temps avant de pouvoir accéder aux objets git. Si cela prend plus de 5 minutes, assurez-vous de contacter le support GitHub.

J'ai mal compris cela et j'ai supposé que nous allions seulement pouvoir lancer un processus de fork, passer à autre chose et ne pourrons sûrement pas attendre un objet de réponse qui renvoie les détails du nouveau fork parce que nous ne le faisons pas. lorsque le processus de fork est terminé.

Cette hypothèse m'a obligé à ne renvoyer aucune donnée de la fonction principale de forkRepository et je commençais déjà à réfléchir à ce stade : comment vais-je faire en sorte que les détails du fork soient traités pour la phase suivante du processus de contribution !? Hmm, je vais peut-être utiliser des webhooks ?!?

Il s'est avéré que j'y réfléchissais trop ?, j'ai réalisé plus tard que j'obtiendrais en fait les détails de la réponse pour le fork et cela m'a amené à faire un PR de suivi pour traiter du retour des données requises de l'objet de réponse du fork pour la consommation dans le processus de contribution.

Les relations publiques

Principal:

exploit : implémenter le script du référentiel `fork` #3

babillage publié le 31 décembre 2023

Cette Pull Request implémente le script fork ; ce script est destiné à être utilisé pour transférer par programme le dépôt principal du projet vers un compte utilisateur ; Il héberge une fonction principale et d'autres fonctions d'assistance qu'il utilise pour effectuer certaines actions nécessaires afin de garantir un fonctionnement efficace du repo fork.

Modifications apportées

• Implémentation de la fonction principale forkRepository dans le script ; cette fonction est la fonction exportée principale qui effectue l'opération de fork principale ; il accepte une instance userOctokit (un objet authentifié par l'utilisateur avec l'autorisation d'agir au nom de l'utilisateur) et les détails du référentiel du projet, c'est-à-dire l'objet repoDetails et il effectue les opérations suivantes...
  • Il vérifie si le référentiel du projet a déjà été transféré sur le compte de l'utilisateur à l'aide de la fonction d'assistance isRepositoryForked ; cela renvoie le fork de null
    • Si le dépôt a déjà été forké, nous vérifions si le fork est à jour/synchronisé avec le dépôt principal du projet à l'aide de la fonction d'assistance isRepositoryForkUpdated ; cela renvoie le updateSHA et une propriété booléenne isUpdated qui confirment si fork est à jour
      • Si fork n'est pas à jour ; puis nous effectuons la mise à jour en la synchronisant avec le dépôt principal du projet à l'aide de la fonction d'assistance updateRepositoryFork
    • Si le dépôt est à jour/synchronisé avec le dépôt principal du projet ; nous annulons l'opération à ce stade avec un retour anticipé ;
  • Si le référentiel du projet n'est pas transféré sur le compte de l'utilisateur ; nous procédons ensuite au lancement d'un processus fork en appelant le point de terminaison "POST /repos/{owner}/{repo}/forks" à l'aide de l'instance userOctokit. (Cela démarre le processus de fork, nous ne savons pas exactement quand le processus se termine ?)
• Implémentez les fonctions d'assistance suivantes utilisées dans la fonction principale forkRepository et dans d'autres fonctions d'assistance également
  • updateRepositoryFork - utilisé pour mettre à jour le référentiel (Sync) vers l'état du référentiel principal (tête)
  • isRepositoryForkUpdated - utilisé pour vérifier si un fork est (en synchronisation avec le dépôt principal) à jour avec le dépôt principal
  • getBranch - utilisé pour récupérer les détails d'une branche/référence
  • isRepositoryForked - utilisé pour vérifier la présence d'un dépôt spécifique dans la liste des dépôts fork d'un utilisateur
• Ajout de getRepoParts à /lib/utils ; c'est une fonction utilitaire utilisée pour résoudre repoOwner et repoName à partir du nom complet d'un référentiel.

Problème connexe

Résout n° 2

Diffusion d'écran/Capture d'écran

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

?

Voir sur GitHub

exploit : renvoyer le dépôt `fullname` dans le script fork #29

babillage publié le 04 avril 2024

Ce PR fait suite à une étape manquante dans la mise en œuvre initiale du script fork au n°3 ; le script fork n'a pas réussi à renvoyer un dépôt qui peut être utilisé lors de la prochaine étape du calcul. C'était à cause d'une hypothèse étrange que j'avais lors de la mise en œuvre initiale. ?Voir mon hypothèse ci-dessous...

Je suppose que l'appel au point de terminaison "POST /repos/{owner}/{repo}/forks" assure uniquement le lancement d'un processus fork sans nous assurer du tout d'une réponse. Cela signifie que nous pourrions ne pas obtenir exactement de réponse.données après l'appel

... mais ce n'était pas vrai, j'ai découvert qu'une réponse.data arrive réellement, mais cela peut prendre un certain temps et seulement dans les cas où le dépôt en cours de fork est énorme.... et pour le moment la création du dépôt du projet se produit en moins de 5 secondes.

Modifications apportées

• Repo fork renvoyé - il s'agit d'une valeur de nom complet du dépôt renvoyée par la fonction d'assistance isRepositoryForked ; Je le renvoie par la présente comme valeur renvoyée principale par l'exécution de la fonction forkRepository dans la condition où le dépôt est déjà bifurqué sur le compte d'un utilisateur en cours d'exécution
• Response.data.full_name renvoyée - il s'agit d'un nom complet de dépôt fork nouvellement créé ; Il s'agit d'une valeur provenant de la réponse à l'appel du point de terminaison « POST /repos/{owner}/{repo}/forks » ; Je le renvoie par la présente comme valeur principale réajustée à partir de l'exécution de la fonction forkRepository dans les cas où aucun fork n'a déjà été trouvé sur le compte de l'utilisateur en cours d'exécution
• Cherry a sélectionné quelques modifications du n°25 à utiliser ici
  • f12f25f548a5c5836e9be7d601ed226c5269f5ee
  • 436ceea649b67812c0ec1164fde95d443ce556e0

?

Voir sur GitHub