Dies ist das erste von vier Skripten, die ich gemäß der Systemarchitektur schreiben wollte. Fühlte mich aufgepumpt! Es war ein Schritt in Richtung der Schaffung des „Wiki“-Erlebnisses, das einen Beitrag zu Open Source ohne Schnittstelle zur GitHub-Benutzeroberfläche erhält.

Was sind das für Skripte?

Dies sind JS-Dateien, die einige verwandte wiederverwendbare Funktionen enthalten, die insbesondere für die Interaktion mit den GitHub-APIs gedacht sind; Sie werden entweder im selben Skript verwendet oder exportiert, um an anderer Stelle im Projekt zur Ausführung ihrer Grundfunktionalität verwendet zu werden. Sie akzeptieren eine authentifizierte Octokit-Instanz eines Benutzers als Parameter von anderen. Diese Instanz wird verwendet, um Aktionen/Funktionen über die GitHub-APIs im Namen des authentifizierten Benutzers auszuführen.

Die Notwendigkeit, einen Beitragsfluss zu Open Source ohne Schnittstelle zur GitHub-Benutzeroberfläche zu erstellen, bedeutete, dass wir einen Prozess automatisieren mussten – indem wir alle Schritte simulierten, die ein Benutzer unternehmen würde, wenn er über die GitHub-Benutzeroberfläche beitragen würde. Die Schritte sind wie folgt folgt..

1. Fork-Projekt-Repo
2. Zweig erstellen
3. Änderungen an der Verzweigung festschreiben (fügen Sie in unserem Fall eine neue MDX-Datei im Verzeichnis src/pages/word/ für ein neues Wort hinzu oder bearbeiten Sie vorhandene)
4. Erstellen Sie eine Pull-Anfrage (übermitteln Sie in unserem Fall die Wortänderungen)

Eine Wahrheit, die es wert ist, ausgesprochen zu werden

Ich habe gleich nach dem ersten Commit mit dem Schreiben dieses Skripts begonnen, das war tatsächlich die PR Nr. 2, aber es hat während der langen einmonatigen Pause einen Rückschlag erlitten? Ich habe aus dem Projekt übernommen, bevor ich mich wieder an die Arbeit an der Basiswörterbuchfunktion gemacht habe.

Das Drehbuch

Die Aufgabe hier bestand darin, „The Fork Script“ zu erstellen – dessen Endziel darin besteht, einen Fork des jargons.dev-Repos auf/von einem Benutzerkonto zu erstellen/abzurufen. Es sollte jede Funktion enthalten, die Folgendes tut.

• Überprüfen Sie, ob im Konto eines Benutzers bereits ein Fork von jargons.dev vorhanden ist
  • Wenn Fork vorhanden ist
    • Überprüfen Sie, ob der Fork mit dem Upstream synchronisiert ist (d. h. auf dem neuesten Stand mit dem Jargons.dev-Repo-Hauptzweig); WENN NICHT – Aktualisieren Sie den Fork
  • Wenn KEIN Fork gefunden wird
    • Erstellen Sie den Fork

Als ich die Aufgabe verstand, „vertiefte“ ich mich direkt in die Arbeit am Drehbuch.

Ich bin bereits sehr an die GitHub-APIs gewöhnt, da ich sie bei meiner täglichen Arbeit an Hearts häufig konsumiere ❤️... Die Fork-Dokumentation von GitHub sah für mich also wie ein Broski aus?...

Die Schritte

• Ich habe eine Hauptfunktion forkRepository erstellt, die den Haupteinstiegspunkt für die Ausführung der Fork-Funktionalität darstellte – sie führt überall hin
• Ich habe die folgenden Funktionen hinzugefügt, die hauptsächlich als Hilfsfunktionen für die offensichtliche Hauptfunktion forkRepository dienten
  • isRepositoryForked – diese Funktion prüft, ob das jargons.dev-Repository bereits auf das Konto des aktuellen authentifizierten Benutzers geforkt wurde
  • isRepositoryForkUpdated – um zu überprüfen, ob der Fork (falls gefunden) (in Synchronisierung mit dem Head-Repo) mit dem Haupt-Jargons.dev-Repo auf dem neuesten Stand ist
  • updateRepositoryFork – wird zum Aktualisieren (Synchronisieren) des Repositorys auf den Status des Haupt-(Haupt-)jargons.dev-Repositorys verwendet
  • getBranch – ist ein Basisdienstprogramm (zum Zeitpunkt des Schreibens dieses Skripts erforderlich), das zum Abrufen von Branch-/Ref-Details für das jargons.dev-Repo und den Fork des Benutzers verwendet wird, um sie im Vergleich zu verwenden, der im isRepositoryForkUpdated-Helfer durchgeführt wird, um seine Hauptfunktion auszuführen; Es verwendet den Endpunkt GitHub References.

Meine seltsame Annahme

Geht mir durch den Kopf? Als ich dieses Skript schrieb, war ein Gedanke, an dem ich festhielt, nachdem ich den unten zitierten Absatz in der GitHub Fork-Dokumentation gelesen hatte

Hinweis: Das Forken eines Repositorys erfolgt asynchron. Möglicherweise müssen Sie eine kurze Zeit warten, bevor Sie auf die Git-Objekte zugreifen können. Wenn dies länger als 5 Minuten dauert, wenden Sie sich unbedingt an den GitHub-Support.

Ich habe das falsch verstanden und bin davon ausgegangen, dass wir nur einen Fork-Prozess initiieren, weitermachen und sicher nicht auf ein Antwortobjekt warten können, das die Details des neuen Forks zurückgibt, weil wir es nicht wissen wenn der Fork-Prozess abgeschlossen ist.

Diese Annahme zwang mich dazu, keine Daten von der Hauptfunktion forkRepository zurückzugeben, und ich begann zu diesem Zeitpunkt bereits darüber nachzudenken: Wie bekomme ich die Fork-Details zur Verarbeitung in die nächste Phase des Beitragsprozesses? Hmm, vielleicht verwende ich Webhooks?!?

Es stellte sich heraus, dass ich zu viel darüber nachgedacht hatte? Später wurde mir klar, dass ich tatsächlich Antwortdetails für den Fork erhalten würde, und dies veranlasste mich, eine Folge-PR durchzuführen, um die Rückgabe der vom Fork-Antwortobjekt für die Verwendung in erforderlichen Daten zu beheben Der Beitragsprozess.

Die PR

Hauptsächlich:

Kunststück: „Fork“-Repository-Skript implementieren #3

plapperbey gepostet am 31. Dezember 2023

Dieser Pull Request implementiert das Fork-Skript; Dieses Skript soll verwendet werden, um das Hauptprojekt-Repository programmgesteuert auf ein Benutzerkonto zu übertragen. Es beherbergt eine Hauptfunktion und andere Hilfsfunktionen, mit denen es einige notwendige Aktionen ausführt, um einen effizienten Repo-Fork-Betrieb sicherzustellen.

Änderungen vorgenommen

• Die Hauptfunktion forkRepository innerhalb des Skripts implementiert; Diese Funktion ist die wichtigste exportierte Funktion, die die Hauptverzweigungsoperation ausführt. Es akzeptiert eine userOctokit-Instanz (ein vom Benutzer authentifiziertes Objekt mit der Berechtigung, im Namen des Benutzers zu handeln) und die Repository-Details des Projekts, d. h. das repoDetails-Objekt, und führt Folgendes aus ...
  • Überprüft mithilfe der Hilfsfunktion isRepositoryForked, ob das Projekt-Repository bereits auf das Konto des Benutzers geforkt wurde. Dies gibt die Abzweigung von null zurück
    • Wenn das Repo bereits geforkt wurde, führen wir mithilfe der Hilfsfunktion isRepositoryForkUpdated eine Prüfung durch, ob die Verzweigung aktuell/synchron mit dem Hauptprojekt-Repo ist; Dies gibt die aktualisierte SHA und eine boolesche isUpdated-Eigenschaft zurück, die bestätigt, ob Fork auf dem neuesten Stand ist
      • Wenn der Fork nicht aktuell ist; Anschließend führen wir das Update durch, indem wir es mithilfe der updateRepositoryFork-Hilfsfunktion mit dem Hauptprojekt-Repository synchronisieren.
    Wenn das Repo aktuell/synchron mit dem Hauptprojekt-Repo ist; wir brechen den Betrieb an dieser Stelle mit einer vorzeitigen Rückkehr ab;
  Wenn das Projekt-Repository nicht auf das Konto des Benutzers aufgeteilt ist; Anschließend initiieren wir einen Fork-Prozess, indem wir den Endpunkt „POST /repos/{owner}/{repo}/forks“ mithilfe der userOctokit-Instanz aufrufen.
  • (Dies startet den Fork-Prozess, wir wissen nicht genau, wann der Prozess abgeschlossen ist?)
Implementieren Sie die folgenden Hilfsfunktionen, die in der Hauptfunktion forkRepository und auch in anderen Hilfsfunktionen verwendet werden
• updateRepositoryFork – wird zum Aktualisieren (Synchronisieren) des Repositorys auf den Status des Haupt-(Haupt-)Repositorys verwendet
  isRepositoryForkUpdated – wird verwendet, um zu überprüfen, ob ein Fork (in Synchronisierung mit dem Haupt-Repo) mit dem Haupt-Repo auf dem neuesten Stand ist
  getBranch – wird zum Abrufen von Branch-/Ref-Details verwendet
  isRepositoryForked – wird verwendet, um zu prüfen, ob ein bestimmtes Repo in der Fork-Repo-Liste eines Benutzers vorhanden ist
getRepoParts zu /lib/utils hinzugefügt; Es handelt sich um eine Dienstprogrammfunktion, die zum Auflösen von repoOwner und repoName aus einem Repository-Vollnamen verwendet wird.

Verwandtes Problem

Löst #2

Screencast/Screenshot

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

?

Auf GitHub ansehen

feat: Repo „fullname“ im Fork-Skript zurückgeben #29

plapperbey gepostet am 4. April 2024

Diese PR ist eine Folgemaßnahme zu einem fehlenden Schritt in der ersten Implementierung des Fork-Skripts bei #3; Das Fork-Skript konnte kein Repo zurückgeben, das im nächsten Berechnungsschritt verwendet werden kann. Dies lag an einer seltsamen Annahme, die ich bei der ersten Implementierung hatte. ?Siehe meine Annahme unten...

Ich gehe davon aus, dass der Aufruf des Endpunkts „POST /repos/{owner}/{repo}/forks“ lediglich die Initiierung eines Fork-Prozesses gewährleistet, ohne uns überhaupt eine Antwort zuzusichern. Das bedeutet, dass wir nach dem Aufruf möglicherweise nicht genau eine Antwort erhalten.data

...aber das stimmte nicht, ich habe herausgefunden, dass tatsächlich eine Antwort.Daten kommt, aber es kann nur einige Zeit dauern und nur in Fällen, in denen das gespaltene Repo riesig ist... und im Moment Das Forken des Projekt-Repos erfolgt in weniger als 5 Sekunden.

Änderungen vorgenommen

Zurückgegebenes Fork-Repo – dies ist ein Repo-Vollnamenswert, der von der isRepositoryForked-Hilfsfunktion zurückgegeben wird; Hiermit gebe ich es als Hauptrückgabewert aus der Ausführung der forkRepository-Funktion in dem Zustand zurück, in dem das Repo bereits auf das Konto eines ausführenden Benutzers geforkt wurde
Zurückgegebener „response.data.full_name“ – dies ist der vollständige Name eines neu erstellten Fork-Repos; Es handelt sich um einen Wert aus der Antwort auf den Endpunktaufruf „POST /repos/{owner}/{repo}/forks“. Hiermit gebe ich ihn als neu abgestimmten Hauptwert aus der Ausführung der forkRepository-Funktion zurück, in Fällen, in denen im Konto des ausführenden Benutzers noch kein Fork gefunden wurde
Cherry hat einige Änderungen aus Nr. 25 ausgewählt, um sie hier zu verwenden
• f12f25f548a5c5836e9be7d601ed226c5269f5ee
  436ceea649b67812c0ec1164fde95d443ce556e0

?

Auf GitHub ansehen