GitHub Codespaces で開発する

Why
開発時のローカルマシンの負荷を下げたい
開発を開始する際のローカルマシンの環境構築を軽くしたい or なくしたい
特にインターンなどを受け入れる際のオンボーディングコストを下げたい
VSCode で使う
事前準備
​GitHub Codespaces の VSCode 拡張 をインストールする
新しい Codespace を作る
そのリポジトリではじめて Codespacse を使う場合。
Command Pallete から Codespaces: Create New Codespace を実行
リポジトリ名, ブランチを選択
マシンスペックを選択
Web Frontend の場合は 8 cores / 16 GB RAM / 64 GB storage 以上を推奨しています
既に存在する Codespace をアタッチする
そのリポジトリで Codespace を利用していたが、何らかの理由（VSCode 閉じた etc.）により Codespace に接続しているウィンドウがなくなった場合。 もしくは、GitHub Web から起動した Codespace をデスクトップアプリから開きたい場合。
Command Pallete から Codespaces: Connect to Codespace を実行
Codespace を終了する
GitHub Codespaces ではインスタンス稼働時間に対して課金されるため、作業が終わった Codespace は停止しておくことが推奨されます。
Command Pallete から Codespaces: Stop Current Codespace を実行
その Codespace を再利用する予定がしばらくなければ、Command Pallete から Codespaces: Delete Codespace を実行し Codespace を消しておく
また、inactive な状態で一定時間（30分） 経過すれば自動で停止されます。
Codespace を削除する
停止中の Codespace ではストレージ使用量に対してのみ課金されます。 しばらくそのリポジトリで作業することがないのであれば、Codespace を削除しておきましょう。
Command Pallete から Codespaces: Delete Codespace を実行し、不要になった Codespace 選択する
これはコスト節約の側面もありますが、それ以上に次回起動時に新しい Codespace を作ることで、いきなり最新の開発環境で作業をスタートできるという生産性上の利点も大きいです。
ブラウザで使う
事前準備
特に必要ありません。
新しい Codespace を作る
Codespaces を使いたいリポジトリを開きます。 緑色の Code ボタンをクリックし、New Codespaces をクリックします。
top
その後、環境のスペックを選択すると、 Codespaces が起動します。
editor
Codespace を削除する
GitHub を開き、自分のアイコンから Your Codespaces をクリックします。
codespaces
delete をクリックすることで 使い終わった Codespaces を削除することができます。
deletecodespaces
このページには自分が作成した Codespaces のみ表示されます。
Tips
kube や kube fork を使う
Wantedly のリポジトリには順次 kube などの社内ツールを上手くつかうための設定を展開しています。 展開済みのリポジトリでは特別な設定や Access Token 発行なしに kube を使うことができます。
ローカルマシンと同じ設定を使う
GitHub Codespaces には <username>/dotfiles リポジトリが存在し、そこにインストールスクリプトっぽいものがあればそれを自動的に clone, 実行してくれる機能があります。 普段使っている Shell の設定を引き継ぎたいときや、普段遣いのツールを入れたい（たとえば grep ではなく ag や ripgrep を使いたい）場合は dotfiles リポジトリを作るといいかもしれません。
詳しくは公式ドキュメント Personalizing Codespaces for your account - GitHub Docs を参照してください。
VSCode 拡張を入れる
VSCode 拡張には UI Extension と Workspace Extension の2種類が存在します。 詳しい説明は公式ドキュメント Supporting Remote Development and GitHub Codespaces に譲りますが、 前者はローカルマシン、後者が Worksapce と同じマシン（Codespace ならリモートに作られるコンテナ）にインストールされ、そのマシン上で動作します。
UI Extension は普段利用している VSCode に入っているものがそのまま利用されます。 一方で Workspace Extension は Codespace を新しく作るたびにインストールし直す必要があります。
そのリポジトリの開発で絶対必要で、かつ他の開発者にも使ってほしい拡張がある場合は、.devcontainer/devcontainer.json の extensions という項目に追加することで、Codespace を作ると必ずその拡張が入るようになります。 なお、.devcontainer/devcontainer.json は全開発者に共通する設定になるので、編集する場合は必ずレビューを受けましょう。
Codespaces を設定する
どんなリポジトリでも、.devcontainer の設定をすることで 起動する Codespaces をカスタマイズすることができます。
.devcontainer
.devcontainer に環境についての設定を書くと、Codespaces 起動時にその設定が読み込まれ、任意のコンテナで起動することができるようになります。
​wantedly-frontend(internal) の設定がまとまっています。
新しく .devcontainer の設定をいれたいとき
新しく Codespaces を使うことを決めたリポジトリでは、.devcontainer の設定をすることがおすすめです。
理由としては、次の２つが挙げられます
kube など、必要なツール群が入っていない
汎用的な環境の言語のバージョンと、リポジトリで利用している言語のバージョンが異なっている場合がある
Codespaces が起動したあと、コマンドパレットから Codespaces: Add Development Container Config... を選択します。
config
ベースイメージのリストが出てくるので、環境にあったものを選択します。 ここで選択したイメージは Codespaces が利用するホストにキャッシュされており、起動が比較的早いです。
イメージを選択すると、各種設定が .devcontainer/ に保存されます。このファイルをコミットすると、他の人も同じ環境で起動することができるようになります。
おすすめ設定
細かい設定については devcontainer.json reference を参照してください
script/codespaces/bootstrap
起動後に実行したいスクリプトをまとめた bootstrap ファイルを用意しておくと良いです。
./devcontainer/devcontainer.json
PATH には、kube がインストールされる path を含めておくと良いです。
script/codespaces/bootstrap のような起動後に実行したいスクリプトをまとめたファイルを用意し、postCreateCommand で実行すると良いです
postCreateCommand は codespace が起動した後に実行されます
telepresence を利用する場合、 runArgs に以下の設定が必要です。
{
  "remoteEnv": {
    "PATH": "/home/node/.wantedly/bin:${containerEnv:PATH}"
  },
​
  // Use 'postCreateCommand' to run commands after the container is created.
  "postCreateCommand": "script/codespaces/bootstrap",
​
  "runArgs": ["--cap-add=NET_ADMIN", "--cap-add=NET_BIND_SERVICE"],
}
話を聞きに行きたい
Slack: #dx​

最終更新 1yr ago