GitHub Copilot Workspaceを実際のOSS開発で試してみたメモ

まずは日本語でこういう機能を追加したいと書いてみる。
GCSにJSONLを配置する際にBQでパーティションを有効化できるようにファイルパスはユーザーがある程度任意で組み立てられるようにする必要があることは前から考えていた。
JSONLをGCSに置くという基本機能に加えて、この機能も伝えてみる。

ブレストの内容を見た感じ、全然ダメそう。今のCIAnalyzerのクラス設計の理解が足りていないように見える

The GcsStore class in src/store/gcs_store.ts handles reading and writing files to GCS but does not include logic for generating filenames with {workflow_id}-YYYYMMddhhmmss.json.

ややこしいのだが、gcs_store.tsはデータのエクスポートではなくて、最後にAPIからデータを取得したジョブのID番号をGCSに保存するクラスである。今回はExporterとしてGCSに保存するクラスが新規に必要になるはずなので間違っている

The BigqueryExporter class in src/exporter/bigquery_exporter.ts handles exporting reports to BigQuery but does not include logic for generating filenames with {workflow_id}-YYYYMMddhhmmss.json.

これもほぼ同じ話だが、BigqueryExporterはBQにエクスポートするためのクラスなのでGCSにエクスポートする機能はここに追加するのではなく、新しいクラスを作りたい

これを見てCopilot Workspace使えないなーと決めるのは簡単だが、ブレストの段階で訂正できるので頑張ってみる。

まず下のチャット欄に入力したら追加で指示を出せるのだろうか？と思ったので試してみる

そうしたらブレストの内容が全部書き換わってしまった？

と思ったら、これは新しいブレストを作成したということらしく、最初のブレスト（How do I solve this task?）というログはちゃんと残っていた。

ということは、issueを解決するためのブレスト -> プラン -> コード生成は一発の一筆書きではなく、自分でサブタスクに分解して個々にブレストをから始められるということだろうか？

改めて先ほど新しく作成したブレストの内容を見てみる

GCSにJSONLをエクスポートする機能はsrc/exporter/gcs_exporter.tsという新しいファイルを作成し、Exporterインターフェースを継承したGcsExporterクラスを作成してそこに実装してください

これに対して、

To implement the functionality to export JSONL to GCS, you need to create a new file src/exporter/gcs_exporter.ts and implement the GcsExporter class that extends the Exporter interface. Here are the steps to achieve this:

• Create a new file src/exporter/gcs_exporter.ts.
• Implement the GcsExporter class in this file.
• Ensure that the GcsExporter class extends the Exporter interface.

このあたりまでは日本語を英訳したぐらいの情報しかない。

You can refer to the existing BigqueryExporter class in
src/exporter/bigquery_exporter.ts
and LocalExporter class in
src/exporter/local_exporter.ts
for guidance on how to structure the new GcsExporter class.

ここからは特に自分は指示していないのでCopilotが自力で導いている。特にBigqueryExporterに加えてLocalExporterを参照することは自分は一言も書いていなかった。けどこの2つ同じExporterクラスを継承しているため、参照することは正しい。

Additionally, you may need to update the configuration schema in
src/config/schema.ts
to include the new GCS exporter configuration options.

ここは完全に指示していなかった。たしかにGCSのバケットや配置するパスなどを指定するためにconfig.ymlの設定を拡張する必要があり、config/schema.tsは設定ファイルの型定義をzodで行っているので、ここを拡張することも正しい。

もともとセットされていた How do I solve this task? というブレストを削除して、代わりに今作成したブレストを Add to task ボタンでセット。
これでPlanを作成するとこうなった

ちゃんとさっきのブレストの内容を反映したプランになっていて、最初に考えていたYYYYMMddhhのようなプレースホルダーの話は消えている。
その機能は後で実装しよう。

このプランでコード生成させてみる。

おいおい、プランには特に書かれていなかったYYYYMMDDhhmmssのプレースホルダーも実装してくれたらしい。（余計なお世話・・・）

このコードがちゃんと動くかどうかは精査する必要があるが、その前に新しく追加する @google-cloud/storage はpackage.jsonに追加しないと絶対に動かないと分かっているのでそれは追加してもらう。

下のチャット欄にこんな感じで @google-cloud/storage を追加してもらうように指示を出してみた

するとプランに Commands が追加されて、 npm install @google-cloud/storage というタスクが追加された。

いかにも実行できそうボタンが右側にあるので実行してみるとCodespaceの立ち上げが始まった。コマンドを実行するためにはさすがにLinux環境が必要なのでCodespacesで用意するのか。すごい。

Codespaceが立ち上がって npm install が実行されるとpackage.jsonとpackge-lock.jsonのdiffも追加された。

diffを見たら新規追加ではなくてバージョンアップになっていた。そういえばCIAnalyzerはもともと @google-cloud/storage を使っていたのでインストールする必要はなかったのか。
codespacesのターミナルが開いているのでここで git restore で差分を消しておく。

ここまででパッと見た感じでは、ci_analyzer.yamlにエクスポート先のGCSのバケットのパスを指定する設定を追加して動かせば動きそうに見えなくもない。
けど実際に動かしてみないと本当に動くかどうか作者の自分でもよくわからない。このブラウザのCopilot Workspaceの画面では1ファイルが表示されている領域が狭いのと、diffがあるファイルしか表示されていないので既存コードとの比較がしにくい。

Copilot Workspaceからpull-requestも作れるみたいだが、いったん別ブランチにコミットして保存しておく。

"Push to new branch"に切り替えてボタンをクリックしたらコミットメッセージの画面が出てきた。

適当にコミットメッセージを書いてpush。続きは自分のVSCodeでやろう

実はVSCodeにもCopilot WorkspaceのExtensionがあるらしい（11/21時点ではpreview）ので入れてみた。
https://marketplace.visualstudio.com/items?itemName=GitHub.copilot-workspace

さっきまでブラウザで行っていたCopilot Workspaceのセッションを開いてみるとこんな感じ。

ブレストの細かい指示文章が表示されていないが、Planの方は反映されている。ということは、ここからPlanに指示を追加してコード生成をやりなおさせたりもできるのかな？

もはやgs://と{reportType}は自分で書き直したが、最終的にGCSのSDKに渡すパスとしてはgs://を削除する必要があるのと、パスのテンプレートの{YYYY}や{MM}といった時刻はともかく{reportType}は必ず与えられている必要があることに気が付いた。

これも自分でコードを書いてもいいのだが、せっかくなのでVSCode内のCopilot Workspaceに今度は手動でPlanの箇条書きに追加してみる

この状態でPlanから再実装をさせてみたら{reportType}が含まれているかどうかのチェックは出してくれた。

    if (!this.pathTemplate.includes("{reportType}")) {
      throw new Error(
        "The 'pathTemplate' parameter must include '{reportType}' variable.",
      );
    }

が、gs://を消すという実装は実装してくれなかった。

ここまでの感想としては、Copilot Workspaceに任せる価値がある仕事はコード全体にまたがって大枠の修正や新規ファイルの追加が必要な初期実装かなと思った。

1ファイルの差分行を細かく見ていくとCopilot Workspaceが出してくれたコードには観点が抜けていたり、細かい部分で気に入らない実装があったりする。けどそういう部分に関しては手作業や、従来のCopilotのタブ補完とかCopilot Chatで直していく方が早い。

抽象的な概念で説明すると、今まで既存のコードベースに機能を追加する場合に自分はこのように作業していた

1. 出力する成果物のフォーマットや、設定ファイルに追加するスキーマを考える
2. コード全体から追加機能に関連しそうなファイルを調べ、きれいにハマりそうなクラス・インターフェース設計を考える
3. 新規クラスや関数が必要な場合は、似ている既存のコードをコピペしてきてから修正する
4. 実際に動かしてみて、細かいところを修正する
5. 思い付くコーナーケースについてユニットテストを書いて、ちゃんとカバーできているかを確認する

Copilot Workspaceを使うと、1-3までの工程の大枠はやってくれそうな雰囲気を感じる。5も多分Planに追加すればテストコードを作ってくれると思うが、自分の場合はテストコードを書く目的がコーナーケースのカバーであることが多いので、そのような目的だとCopilot Workspaceの段階よりは後にならざるを得ないので従来のCopilot Chatとかにお願いした方が効率がよさそうな気がした。