これは、システム アーキテクチャに記載されているように、私が作成しようとした 4 つのスクリプトのうちの最初のスクリプトです。気分が盛り上がった！これは、GitHub UI とインターフェースせずにオープン ソースへの貢献を得る「Wiki」エクスペリエンスを作成する方向への一歩でした ?.

これらのスクリプトは何ですか?

これらは、特に GitHub API と対話するために使用される、関連する再利用可能な関数をいくつか保持する js ファイルです。これらは、同じスクリプト内で使用されるか、プロジェクト内の他の場所で基本機能を実行するためにエクスポートされます。ユーザーの認証された Octokit インスタンスを他のパラメーターとして受け入れます。このインスタンスは、認証されたユーザーに代わって GitHub API を介してアクション/機能を実行するために使用されます。

GitHub UI とインターフェースせずにオープンソースに貢献するフローを作成する必要があるため、一部のプロセスを自動化する必要がありました。ユーザーが GitHub UI 経由で貢献する場合に実行するすべての手順をシミュレートします。手順は次のとおりです。続いて..

1. フォークプロジェクトリポジトリ
2. ブランチを作成する
3. ブランチへの変更のコミット (新しい単語の src/pages/word/ ディレクトリに新しい mdx ファイルを追加するか、この場合は既存のファイルを編集します)
4. プル リクエストを作成します (この場合、単語の変更を送信します)

述べる価値のある真実

最初のコミットの直後にこのスクリプトを書き始めました。これは実際には PR #2 でしたが、1 か月の長い休暇中にヒットしました。基本辞書機能の作業に戻る前に、プロジェクトから抜粋しました。

スクリプト

ここでのタスクは、「フォーク スクリプト」を作成することでした。その最終目標は、ユーザーのアカウント上で、またはユーザーのアカウントから jargons.dev リポジトリのフォークを作成または取得することです。これには、次のことを行うすべての関数が含まれている必要があります。

• jargons.dev のフォークがユーザーのアカウントにすでに存在するかどうかを確認します
  • フォークが存在する場合
    • フォークがアップストリームと同期しているかどうか (つまり、jargons.dev リポジトリのメイン ブランチと最新であるかどうか) を確認します。そうでない場合 — フォークを更新します
  • フォークが見つからない場合
    • フォークを作成する

課題を理解したので、私はすぐに脚本の作業に「掘り下げて」取り組みました。

Hearts での日々の作業で頻繁に使用しているため、GitHub API にはすでに非常に慣れています ❤️... それで、GitHub のフォーク ドキュメントが私にとってブロスキーのように見えましたか?...

ザ・ステップス

• フォーク機能を実行するための主要なエントリ ポイントであるメインの forkRepository 関数を作成しました。これは他のどこにでもつながります
• 次の関数を追加しました。これらは主に、明らかなメインの forkRepository 関数のヘルパーとして機能します。
  • isRepositoryForked - この関数は、jargons.dev リポジトリが現在の認証されたユーザーのアカウントにすでにフォークされているかどうかを確認します
  • isRepositoryForkUpdated - フォーク (見つかった場合) がメインの jargons.dev リポジトリと最新であるかどうか (ヘッド リポジトリと同期しているかどうか) を確認します
  • updateRepositoryFork - リポジトリをメイン (ヘッド) jargons.dev リポジトリの状態に更新 (同期) するために使用されます
  • getBranch - jargons.dev リポジトリとユーザーのフォークの Branch/Ref の詳細をフェッチするために使用される基本ユーティリティ (このスクリプトの作成時点で必要) で、isRepositoryForkUpdated ヘルパーで行われる比較で使用して主な機能を実行します。 GitHub References エンドポイントを使用します。

私の奇妙な仮定

頭の中を駆け巡る?このスクリプトを書いているとき、GitHub フォーク ドキュメントで引用された以下の段落を読んだ後に持ち続けた考えでした。

注: リポジトリのフォークは非同期で行われます。 git オブジェクトにアクセスできるようになるまで、少し待つ必要がある場合があります。これに 5 分以上かかる場合は、必ず GitHub サポートにご連絡ください。

私はこれを誤解しており、フォーク プロセスを開始して先に進むことしかできず、新しいフォークの詳細がわからないため、新しいフォークの詳細を返す応答オブジェクトを待つことはできないだろうと考えていました。フォークプロセスが完了したとき。

この仮定により、メインの forkRepository 関数からデータを返さないようにする必要があり、この時点ですでに考え始めていました - コントリビューション プロセスの次のフェーズに処理するフォークの詳細をどのように取得するか?うーん、Webhook を使ってみようかな?!?

考えすぎていたことが判明しましたが、後でフォークの応答の詳細を実際に取得することに気づき、これにより、フォーク応答オブジェクトから消費するために必要なデータを返すことに対処するためのフォローアップ PR を行うことになりました。貢献プロセス。

PR

主要：

特技: `fork` リポジトリ スクリプトを実装する #3

おしゃべり 投稿日: 2023 年 12 月 31 日

このプル リクエストはフォーク スクリプトを実装しています。このスクリプトは、メイン プロジェクト リポジトリをプログラムによってユーザー アカウントにフォークするために使用することを目的としています。これには、効率的なリポジトリ フォーク操作を確保するために必要なアクションを実行するために使用する main 関数とその他のヘルパー関数が格納されています。

変更内容

• スクリプト内にメインの forkRepository 関数を実装しました。この関数は、メインのフォーク操作を実行するメインのエクスポート関数です。 userOctokit (ユーザーの代理として動作する権限を持つユーザー認証されたオブジェクト) インスタンスとプロジェクトのリポジトリの詳細 (repoDetails オブジェクト) を受け入れ、次の処理を実行します。
  • isRepositoryForked ヘルパー関数を使用して、プロジェクト リポジトリがユーザーのアカウントにすでにフォークされているかどうかを確認します。これはnullのフォークを返します
    • リポジトリがすでにフォークされている場合は、isRepositoryForkUpdated ヘルパー関数を使用して、フォークが最新であるか、メイン プロジェクト リポジトリと同期しているかどうかをチェックします。これは、フォークが最新かどうかを確認する updatedSHA とブール値の isUpdated プロパティを返します。
      • フォークが最新でない場合。次に、updateRepositoryFork ヘルパー関数
      を使用してメイン プロジェクト リポジトリと同期させて更新を実行します。
    • リポジトリが最新であるか、メイン プロジェクト リポジトリと同期している場合。この時点で操作をキャンセルし、早期に復帰します;
  • プロジェクト リポジトリがユーザーのアカウントにフォークされていない場合。次に、userOctokit インスタンスを使用して「POST /repos/{owner}/{repo}/forks」エンドポイントを呼び出し、フォーク プロセスの開始に進みます。 (これによりフォークプロセスが開始されますが、プロセスがいつ完了するか正確にはわかりません?)
• メインの forkRepository 関数内および他のヘルパー関数内でも使用される次のヘルパー関数を実装します。
  • updateRepositoryFork - リポジトリをメイン (ヘッド) リポジトリの状態に更新 (同期) するために使用されます
  • isRepositoryForkUpdated - フォークが（ヘッド リポジトリと同期している）メイン リポジトリと最新であるかどうかを確認するために使用されます
  • getBranch - Branch/Ref の詳細を取得するために使用されます
  • isRepositoryForked - ユーザーのフォーク リポジトリ リストに特定のリポジトリが存在するかどうかを確認するために使用されます
• getRepoParts を /lib/utils に追加しました。これは、リポジトリのフルネームから repoOwner と repoName を解決するために使用されるユーティリティ関数です。

関連問題

#2 を解決

スクリーンキャスト/スクリーンショット

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

?

GitHub で表示

特技：フォークスクリプトでリポジトリ「フルネーム」を返す #29

おしゃべり 投稿日: 2024 年 4 月 4 日

この PR は、#3 のフォーク スクリプトの初期実装で欠落していたステップのフォローアップです。フォーク スクリプトは、計算の次のステップで使用できるリポジトリを返すことができませんでした。これは、最初の実装時に私が抱いた奇妙な仮定が原因でした。 ?以下の私の仮定を参照してください...

「POST /repos/{owner}/{repo}/forks」エンドポイントへの呼び出しは、応答をまったく保証せずに、フォーク プロセスの開始を保証するだけだと思います。つまり、呼び出し

の後にresponse.dataを正確に取得できない可能性があります。

...しかし、それは真実ではありませんでした。response.data が実際に来ることがわかりましたが、フォークされるリポジトリが巨大な場合にのみ、時間がかかるだけかもしれません...そして現時点ではプロジェクト リポジトリのフォークは 5 秒以内に行われます。

変更内容

• 返されたフォーク リポジトリ - これは isRepositoryForked ヘルパー関数から返されたリポジトリのフルネーム値です。リポジトリが実行ユーザーのアカウントですでにフォークされている状態で、forkRepository 関数の実行からのメインの戻り値として返します
• 返されたresponse.data.full_name - これは新しく作成されたフォーク リポジトリのフルネームです。これは、「POST /repos/{owner}/{repo}/forks」エンドポイント呼び出しに対する応答からの値です。実行中のユーザーのアカウントでフォークがすでに見つかっていない場合は、forkRepository 関数の実行からのメインの戻り値としてこれを返します
• Cherry はここで使用するために #25 からいくつかの変更を選択しました
  • f12f25f548a5c5836e9be7d601ed226c5269f5ee
  • 436ceea649b67812c0ec1164fde95d443ce556e0

?

GitHub で表示