Git

ブログ記事の簡単なリライト作業を、手元のMacではなくサーバー側でも動かすようにしてみました。 やりたいことは、サーバーにブログ用リポジトリを clone して、その中で Codex CLI に記事リライト系の作業を任せ、さらにコミット・push・PR作成までを自動化することです。 実際には gh の権限、privateリポジトリのclone、Codexのログイン、sandbox など、細かいところでつまずいたことがいくつかありました。それらを中心に、備忘録として残しておきます。 やりたかったこと まずはサーバーにSSHでログインし、GitHubリポジトリを用意します。 仮に、clone先は以下とします。 /home/appuser/repos/private-blog ここにブログのprivateリポジトリをcloneして、記事リライト用のバッチ処理から Codex CLI を呼び出します。最終的には、このバッチ処理をcronで定期実行する想定です。 当然、git / gh / codex がシェルで使えるように、サーバー側へ各コマンドをインストールしておく必要があります。 本番サーバーでやるのが怖い場合は、もう1台サーバーを用意するのも現実的です。さくらVPSなら比較的安いですし、私も本格運用するなら別サーバーを用意する予定です。 もちろん、ラズパイなどを使って自鯖で処理させるのも十分ありだと思います。 サーバー側でCodexに作業させるので、本番公開ディレクトリとは必ず分けておきます。 /home/appuser/public-site # 公開用 /home/appuser/repos/private-blog # 作業用clone また、私の場合は、リポジトリのmainブランチも直接編集させず、worktreeを使った別ブランチで作業させるようにしています。 全体の関係は、次のようなイメージです。 今のところ、PRのレビューからbuild / deploy作業までは、人間が担当するようにしています。 そのためローカルMacの出番は、最初の初期設定とPR確認が中心です。そこまで整えば、毎回SSHでサーバーに入って手作業する必要はかなり減ります。 なぜGitHub Actionsではなくサーバー上のcloneで回したか ところで、この手の自動化をChatGPTへ相談すると、かなりの確率で GitHub Actions 案が出てきます。 MicrosoftはGitHubを買収済みで、OpenAIにも大きく投資しています。 Microsoft → GitHubを買収済み Microsoft → OpenAIへ大規模投資 だからActionsが推されるのでは、と邪推したくなるくらい毎回出てきます。もちろん半分冗談です。実際には、定期実行やPR作成までGitHub側で完結できるので、CI/CDの定番案として出てくるのだと思います。以前、VPSへのデプロイでは GitHub CI/CD で VPS へ自動デプロイするまで にまとめたように、Actionsの便利さも確認しています。 それでも今回は、サーバー上のcloneで動かす方を選びました。 理由は主に3つです。 1つ目は、すでにサーバー上で日次処理を動かす前提があったことです。記事リライトはサイト運用のローカルな作業に近く、実行ログや失敗時のworktreeをサーバー上に残せる方が追いやすいと考えました。 2つ目は、秘密情報を増やしたくなかったことです。GitHub Actionsに渡すsecretを増やすより、サーバー側のenvファイルに閉じた方が、今回の小さな運用では見通しがよくなります。 3つ目は、OpenAI API key を新しく使わずに進めたかったことです。Codex CLIはChatGPTログインでも使えるため、今回の確認ではAPI keyを新規発行せず、手元で使っているアカウントのログインで試しました。もちろん、公式にはAPI key認証もあり、CIや完全自動化ではAPI keyの方が向く場面もあります。ここでは「今回の運用では使わなかった」という整理です。 ...

AIコーディングエージェントに複数の作業を同時に任せたい場面があります。 たとえば、片方ではUIを直し、もう片方ではテストを直す。あるいは、A案とB案を別々に試す。こういうとき、同じ作業ディレクトリで同時に編集させると、未コミット変更やブランチ切り替え、同じファイルの編集が絡んでかなり危なっかしくなります。 そこで使えるのが git worktree です。 この記事では、1つのローカルリポジトリから複数の作業ディレクトリを作り、feature/new-feature-a と feature/new-feature-b を別々に進める流れを、実際のコマンドと結果で確認します。 git worktree とは git worktree は、1つのGitリポジトリに複数の作業ディレクトリを紐づける機能です。 普通は1つのリポジトリに1つの作業ディレクトリがあり、その中で git switch や git checkout を使ってブランチを切り替えます。 一方、git worktree を使うと、ブランチごとに作業ディレクトリそのものを分けられます。 /tmp/worktree-demo は main /tmp/worktree-demo-a は feature/new-feature-a /tmp/worktree-demo-b は feature/new-feature-b というように、別々の場所で別々のブランチを同時に開けます。 git checkout との違い git checkout や git switch は、今いる作業ディレクトリの中身を別ブランチへ切り替える操作です。 作業途中の変更があると、切り替え時に止められたり、stashやコミットが必要になったりします。 git worktree は、ブランチを切り替えるのではなく、作業ディレクトリを増やします。なので、main の作業場所を残したまま、A用、B用の作業場所を別に用意できます。 AIエージェントに並列で頼む場合は、この差がかなり大きいです。 検証用リポジトリを作る 今回はブログ本体のリポジトリではなく、/tmp に捨てリポジトリを作って試します。 cd /tmp mkdir worktree-demo cd worktree-demo git init -b main printf '# worktree demo\n' > README.md git add README.md git -c user.name='Demo User' -c user.email='[email protected]' commit -m 'initial commit' ここまでで main ブランチに最初のコミットが1つある状態になります。 ...

この記事では、GitHub で管理している JS ライブラリプロジェクトに対して、タグをpushするだけで VPS へ SSH + rsync で自動デプロイされる GitHub Actions ワークフローを最小構成で作った手順をまとめています。SSH 鍵の準備・GitHub Secrets の登録・deploy.yml の作成まで一通り実装でき、手作業でのデプロイが不要になります。CI/CD の仕組みが「GitHub上のLinuxでシェルを実行するしくみ」だと分かると、他のプロジェクトへの応用も簡単です。 はじめに 2025年の今回初めてGitHubのCI/CDを使ってみてとても便利だったので、やり方・手順を備忘録として残しました。 今回対象となるプロジェクトは個人で開発している小さなjsライブラリプロジェクトです。 https://apppppp.com/kit/nu-js/ https://github.com/aragig/nu-js GitHubで管理・公開しているこのnu.jsにタグをつけてプッシュした時点で、以下の処理をCI/CDで自動化させます。 バージョンタグを取得する コンテンツをビルドする プレースホルダーに①を埋め込む 公開用のVPSサーバーへSSHで接続 rsyncでコンテンツを同期する と、こんな感じです。シェル一発でもできる作業なので、わざわざCI/CDで実現しなくても良さそうではありますが、実際やってみるとこれが結構便利で楽しかったです。なるほど、CI/CDというのはGitHub上にLinuxを立ち上げて、pushなどをトリガーにしてシェルを実行させるような仕組みなのですね！ 仮想のmacOSなども実行できるので、iOSアプリのリリース作業もできそうです。ちょっと今まで使ってこなかったのが、損した気分になるほどCI/CDって便利かもです。 CI/CDとは CI/CDは、ソフトウェアを「こまめに作って、こまめに届ける」ための自動化の仕組みで、まさに先に示した通りです。 CI（Continuous Integration）は、開発者がコードをpushするたびに、自動でビルド・テスト・静的解析を実行して、早い段階で不具合を見つけるしくみ。 CD（Continuous Delivery / Deployment）はテストを通った成果物を「いつでも本番に出せる状態」に自動で用意する（ステージング配置やアーティファクト化まで）。テスト通過後に「本番へ自動リリース」までやる。 こうすることで、早期にバグ検知、手作業ミス削減、リリース頻度向上、レビューと承認の見える化できます。 手順① サーバ側：デプロイ鍵を用意 ここからは実際に個人プロジェクトのデプロイをCI/CDで自動化させた手順をご紹介します。 ローカル（macOS）で鍵を作って、サーバーの authorized_keys に登録します。 # macOS 側で ssh-keygen -t ed25519 -f ~/.ssh/nujs_deploy -C "nu-js deploy" -N "" # cat 方式 cat ~/.ssh/nujs_deploy.pub | ssh [email protected] 'mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys' 手順② GitHub Secrets を登録 リポジトリ Settings → Secrets and variables → Actions に以下を追加します。 ...