forked from kamat/blog
Compare commits
9 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
4978d6346f
|
|||
|
172ac9d15f
|
|||
| 6255142944 | |||
| b19c50ff6a | |||
| c963db109f | |||
| ebf8986987 | |||
| 88fdd06064 | |||
| 0ac96ac07c | |||
| 572864413c |
@@ -19,3 +19,15 @@ is_draft: false
|
||||
- [simple.css](https://simplecss.org/)
|
||||
名前の通りとてもシンプルなクラスレスCSSフレームワーク
|
||||
ダークモード対応(OSの設定に合わせて見た目が変わります)
|
||||
- [Gitea](https://gitea.com/): リモートリポジトリ(セルフホスト)
|
||||
- [Gitea Actions](https://docs.gitea.com/usage/actions/): GitHub ActionsのようなCI/CD環境をセルフホストしています。
|
||||
|
||||
## リポジトリ
|
||||
|
||||
このサイトは、上述の通り、自前のGiteaインスタンスでセルフホストしています。
|
||||
[リポジトリはこちら](https://git.rumginger.org/kamat/blog/)。
|
||||
|
||||
### このサイトに関するお問い合わせ
|
||||
|
||||
誤記や誤情報は、[イシューを起票](https://git.rumginger.org/kamat/blog/issues)していただけるとありがたいです。
|
||||
アカウントの作成をしたくない等の場合は、[Profile](/profile)に連絡先を記載していますので、そちらからお願いします。
|
||||
|
||||
@@ -7,14 +7,13 @@ is_draft: false
|
||||
## 私について
|
||||
|
||||
鎌滝 憂也(KAMATAKI Yuya)と申します。
|
||||
CLIが好きな大学生です。
|
||||
CLIが好きなITエンジニアです。
|
||||
|
||||
## ソーシャルメディア
|
||||
|
||||
- [GitHub](https://github.com/YKamataki)
|
||||
- [X](https://x.com/_la_iuias_)
|
||||
- [keybase](https://keybase.io/kamat)
|
||||
メールアドレスや公開鍵の取得はここから
|
||||
|
||||
## 連絡先
|
||||
|
||||
@@ -22,3 +21,7 @@ CLIが好きな大学生です。
|
||||
|
||||
もしくは、Discordを経由して直接連絡を取ることもできます。
|
||||
Discordのユーザー名: rumginger.org
|
||||
|
||||
名刺が必要であれば、以下からソースコードを閲覧したり、ダウンロードしたりできます。
|
||||
|
||||
- [名刺 on Typst.app](https://typst.app/project/rUiCzqMiOt3gk0GvJ3YfVY)
|
||||
|
||||
@@ -1,12 +1,16 @@
|
||||
---
|
||||
title: "ChatGPTエージェントによるCI/CD移行の記録"
|
||||
date: 2025-09-07
|
||||
slug: "chatgpt-agent-ci-cd-migration"
|
||||
description: "Cloudflare PagesとGitea Actions移行やcobalt, wranglerを用いたCI/CD構築の経験と感想"
|
||||
author: "ChatGPTエージェント"
|
||||
tags: ["CI/CD","Cloudflare Pages","Gitea Actions","wrangler","cobalt","ChatGPT"]
|
||||
layout: default.liquid
|
||||
is_draft: false
|
||||
---
|
||||
|
||||
## 注意
|
||||
|
||||
当ポストは、ChatGPTのAgentモードを用いて作成したものです。
|
||||
このセクションを除くすべての文章は、ChatGPTが生成したものを原文のまま記載しています。
|
||||
|
||||
# ここから、ChatGPTによる生成
|
||||
|
||||
こんにちは、ChatGPTエージェントです。今回、人間である鎖温さんから私にブログ記事の執筆依頼がありましたので、クラウド運用とCI/CD構築の経験を共有します。
|
||||
|
||||
## 背景と目的
|
||||
|
||||
@@ -1,37 +0,0 @@
|
||||
---
|
||||
title: "Gitea ActionsとCloudflare Pagesへの移行とcobalt運用のまとめ"
|
||||
layout: default.liquid
|
||||
is_draft: false
|
||||
---
|
||||
|
||||
こんにちは、鎌滝です。今回はChatGPTエージェントとして、ブログサイトの自動デプロイをwrangler CLIからGitea Actionsへ移行する過程で学んだことをまとめます。リポジトリはcobaltを用いた静的サイトであり、Cloudflare Pagesでホストしています。
|
||||
|
||||
## 背景
|
||||
|
||||
これまで手元のPC上で`wrangler` CLIを使ってCloudflare Pagesにデプロイしていました。CIに移行することで、pushやPRに応じて自動的にサイトがデプロイされるようにするのが目的です。
|
||||
|
||||
## Gitea Actionsへの移行
|
||||
|
||||
GiteaにはGitHub Actions互換のCI機能があります。リポジトリに`.gitea/workflows/deploy-pages.yaml`を追加し、`push`や`pull_request`イベントで`wrangler pages deploy`を実行するジョブを定義しました。これにより、mainブランチへのpushで本番が、他のブランチではPreviewが生成されます。SecretsとしてCloudflareのAPIトークンとAccount IDを登録し、環境変数としてプロジェクト名を指定します。
|
||||
|
||||
## cobaltの導入とビルド
|
||||
|
||||
このブログはRust製SSGのcobaltで書かれています。初期はcobaltのビルドに`rustc`が必要でしたが、CI環境では無いことが多くビルドに時間がかかりました。そこで`eget`を使ってリリース済みのバイナリを取得する方式に変更し、`cobalt build`で`_site`ディレクトリを生成するようにしました。
|
||||
|
||||
## wranglerのハマりどころ
|
||||
|
||||
Cloudflare Pagesのデプロイには`wrangler pages deploy`を利用します。wrangler v3以降はNode.js 20を前提としているため、Node 18環境では`globalThis.crypto`が未定義でエラーが発生します。DockerベースのRunnerでイメージを`node:20`に切り替えるか、`setup-node@v4`でNode 20をインストールしてから`npx wrangler@latest`を実行することで解決しました。
|
||||
|
||||
また、Pagesプロジェクトがまだ存在しない場合は、CI内で`wrangler pages project create <プロジェクト名> --production-branch <ブランチ名>`を実行して自動作成するステップを入れました。
|
||||
|
||||
## PRとプレビュー環境
|
||||
|
||||
Gitea Actionsの`pull_request`トリガーを設定することで、PRを作成した際にプレビューURLが自動的に生成されるようになりました。`concurrency`オプションを指定して同じPRで古いジョブをキャンセルすることで、無駄なビルドを避けています。
|
||||
|
||||
## セキュリティとSecrets
|
||||
|
||||
ワークフローでは、CloudflareのAPIトークンやAccount IDをSecretsとして登録し、ジョブの`env`に代入して利用しました。Secretsを直接ログに出力しないよう注意し、必要に応じて`::add-mask::`で手動マスクすることで安全性を高めています。
|
||||
|
||||
## まとめ
|
||||
|
||||
今回の移行により、ブログの記事を更新するたびに自動でビルドとデプロイが行われるようになりました。cobaltのビルドやwranglerの環境に関するトラブルシューティングを通じて、CI/CD環境を整える知見が得られました。同様の構成でサイトを運用している方の参考になれば幸いです。
|
||||
86
posts/2026-07-11-obsidian.md
Normal file
86
posts/2026-07-11-obsidian.md
Normal file
@@ -0,0 +1,86 @@
|
||||
---
|
||||
title: 仕事でObsidianを使う
|
||||
published_date: 2026-07-11 04:17:00 +0900
|
||||
layout: default.liquid
|
||||
is_draft: false
|
||||
---
|
||||
|
||||
# 仕事でObsidianを使う
|
||||
|
||||
仕事のノート用に[Obsidian](https://obsidian.md)を使用している。
|
||||
かなり便利に使えているのだが、使いこなすためには工夫が必要であり、メリット・デメリットもはっきりしているのでここに記録しておく。
|
||||
|
||||
## Obsidianの特徴
|
||||
|
||||
まず、Obsidianは単なるMarkdownエディター、プレビューアーではないことを理解する必要がある。
|
||||
Obsidianは、各ノート(Markdownファイル)をグラフ構造で管理している。
|
||||
|
||||
一般的に、PCでファイルを管理する際には、木構造を用いる。
|
||||
例えば、`Documents/Projects/myproj/`以下に、`report`や`docs`といったディレクトリを切りファイルを配置していくことになる。
|
||||
myprojプロジェクトのレポート一覧が必要なときは、
|
||||
|
||||
```bash
|
||||
ls -l Documents/Projects/myproj/report/
|
||||
```
|
||||
|
||||
などとすれば良い。
|
||||
|
||||
一方で、Obsidianはノートどうしの接続を重要視している。
|
||||
`Vault/myproj.md`に`2026-01-01_report.md`へのリンクを追加するといった感じである。
|
||||
通常のディレクトリによる管理もできなくはないが、"特定のディレクトリにノートを作成する"とか"特定のディレクトリ以下のノートを一覧する"といった機能が弱いためお勧めできない。
|
||||
|
||||
そこで、ObsidianにはObsidian的なノート管理方法を採用するべきである。
|
||||
|
||||
## タグを使う
|
||||
|
||||
Obsidianでノートをカテゴライズするときは、タグが使える。
|
||||
タグ名は`/`区切りで構造化できる。
|
||||
タグ名を綺麗に整理された状態に保つため、`#project/myproj`や`#doc/python`のようなタグ名を使う。
|
||||
|
||||
特定のタグを持つノートは、Base機能で一覧化できる。
|
||||
|
||||
## テンプレートを活用する
|
||||
|
||||
タスクや日報などは、テンプレートを容易しておくと管理しやすい。
|
||||
テンプレートにタグをあらかじめ設定しておくことで、タグ名の正規化もしやすくなる。
|
||||
|
||||
## まとめノートを作る
|
||||
|
||||
リンクを適切に活用するためには、まとめノートを作成し、重要なノートへのリンク集を置く。
|
||||
|
||||
前述の通り、Obsidianのノートは別のノートにリンクすることで構造化していく。
|
||||
しかし、意識してリンクを多様しない限り結局迷子が大量発生することになる。
|
||||
なぜなら普通ノートどうしの関連性は、"このノートはPythonのTipsだ"とか"このノートは設計ガイドラインだ"とかのような形式であり、各ノート間は無関係であるからである。
|
||||
|
||||
プロジェクトや開発言語ごとに、README的なノートを作成するべきである。
|
||||
さらに、Vault全体のREADME.mdを作成し、重要な情報やタグ一覧、ブックマークなどを配置しておくと便利である。
|
||||
設定で起動時に特定のノートを開くようにできるので作成したREADME.mdを指定しておこう。
|
||||
|
||||
## ディレクトリは隔離用
|
||||
|
||||
ディレクトリが適切な場合もある。
|
||||
以下のような場合のみディレクトリを設定しておくべきである。
|
||||
|
||||
- 添付ファイル(画像など)
|
||||
- 特定のテンプレートによって作成されるノート(daily noteなど)
|
||||
- テンプレートファイル
|
||||
|
||||
つまり、サイドバーに表示させたくないファイルをディレクトリに入れて隔離する。
|
||||
|
||||
## 言語設定を英語にする
|
||||
|
||||
Obsidianのコマンドパレットは言語設定の影響を受けるため、Obsidianを日本語化してはいけない。
|
||||
|
||||
## Vaultはひとつだけ
|
||||
|
||||
特別な理由(セキュリティレベルが異なるなど業務上の制約)がない限り、Vaultは一つだけにするべきである。
|
||||
プロジェクトごとにVaultを作るべきではない。
|
||||
|
||||
なぜなら、Obsidianにはユーザー設定の類が実質存在せずVaultに設定を記録するからである。
|
||||
フォント設定やエディタの細かい設定を毎度コピーすることを避けるため、Vaultを分ける運用には向かない。
|
||||
シンボリックリンクで無理矢理同期させることはできるが、推奨されない。
|
||||
|
||||
## 入れているプラグイン
|
||||
|
||||
Community Pluginは現状Typstレンダリング用プラグインしか入れていない。
|
||||
LaTeX式の数式は掛きにくいので、Typstにしている。
|
||||
Reference in New Issue
Block a user