概要
Qiitaの記事をGemini-CLI+GitHubリポジトリで管理したい、という思いから始まった本プロジェクト。本記事では、qiita-cli を導入し、最終的にGitHub Actionsによる完全自動投稿・更新パイプラインを構築するまでの、試行錯誤の道のりを記録します。Gemini CLIという強力な相棒と共に、数々のエラーを乗り越えて、他のMkDocs等との統合に成功したので記念に書きました。
なぜGemini-CLI+GitHubで管理したいのか？
- AI DevOpsできる環境をつくりたい: これができればAGIっぽいじゃないですか
- 執筆環境: VSCodeなど、使い慣れたエディタで執筆したい。
- 自動化: 将来的には、他のドキュメントソースから記事を自動生成・投稿したい。
Gemini-CLIによるqiita-cli の導入と最初の壁
まずは公式の qiita-cli を導入。npx qiita new で記事を作成し、ローカルでのプレビューを目指しました。
しかし、最初の壁は認証でした。
Error: ENOENT: no such file or directory, open '/Users/aki/.config/qiita-cli/credentials.json'
ローカルでのプレビューにも認証が必要であり、npx qiita login を実行してブラウザ経由で認証を済ませる必要がありました。
GitHub Actionsによる自動化 - エラーとの戦い
本丸であるGitHub Actionsでの自動化では、さらに多くの「茨の道」が待ち受けていました。
失敗1: タグがない
最初のワークフロー実行は、以下のエラーで失敗しました。
dummy-article: タグを入力してください
qiita-cli は非インタラクティブモードでは、フロントマターの tags が空だとエラーになるようです。
対策: 全ての記事に tags を設定。私のルールに従い、GeminiCLI タグは必須としました。
失敗2: Forbiddenエラー
次に発生したのが 403 Forbidden エラーです。
QiitaForbiddenOrBadRequestError: {"message":"Forbidden","type":"forbidden"}
これは、GitHub Secretsに設定した QIITA_TOKEN の権限不足が原因でした。
対策: Qiitaのアクセストークン設定を見直し、write_qiita スコープを付与した新しいトークンに更新しました。
失敗3: idとupdated_atがない
権限問題を解決したのも束の間、今度は別のエラーが発生。
dummy-article: updated_atは文字列で入力してください
dummy-article: idは文字列で入力してください
新規投稿のつもりで id と updated_at をフロントマターから削除したのが裏目に出ました。qiita-cli はこれらのフィールドが存在し、かつ文字列であることを期待するようです。
対策: フロントマターに id: '' と updated_at: '' を追記。さらに、updated_at にはISO 8601形式の現在時刻を入れることで、最終的に問題を解決しました。
完成したワークフロー
幾多のエラーを乗り越え、完成したワークフローがこちらです。
name: Test Publish Qiita articles
on:
push:
branches:
- qiita # テスト用ブランチ
paths:
- 'qiita/**'
workflow_dispatch:
permissions:
contents: write
jobs:
publish_articles:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: increments/qiita-cli/actions/publish@v1
with:
qiita-token: ${{ secrets.QIITA_TOKEN }}
root: "qiita"
まとめ
qiita-cli とGitHub Actionsの連携は、いくつかの「お作法」を理解する必要がありましたが、一度パイプラインを構築してしまえば、極めて快適な執筆環境が手に入ります。
この茨の道を歩むことになった未来の誰かのために、そして共に戦ってくれた相棒 Gemini CLI に感謝を込めて、この記録を残します。
なお、このブログはGemini CLIが9割書いてます。