GitHub issueを単一のMarkdownとしてexportする方法
問題
最近GitHub issueでTODO管理とかしたり、 Zennのスクラップのように時系列だけで考えをまとめずにメモることが多いです。
しかしGitHub issueはそのままだとテキストデータとして扱いにくいです。記事化したりDeepLに翻訳させるときに問題になります。
ちなみにDeepLのブラウザ拡張機能の、 DeepL Pro特典のページ全体の翻訳はGitHub issueではうまく動きません。というかページ全体翻訳がきちんと動くページの方が少ないと思うんですが、これは自分の環境の組み合わせが悪いんでしょうか?
そこでGitHub CLIに適切なjqのクエリを渡すことで、単一のMarkdown形式でエクスポート出来るコマンドを使っています。
アカウントごとのGitHub Projectsを使った公開TODO管理が割と良い感じ · Issue #145 · ncaq/www.ncaq.netを見る限り2023年3月に作ってるみたいですね。
自分への疑問: Zennを使えば良いのでは?
私は今はQiitaとかZennとか、独自ドメインでのはてなブログすら使っていません。
このサイトはMarkdownからhakyllとその内部のpandocを使って、 HTMLとして出力してCloudflare Pagesでホスティングしています。 Cloudflare Pagesにすら大して依存していなくて単純にHTMLなどを配信しているだけなので、いつでも自宅サーバのNGINXを使ったホスティングに戻すことが可能です。今では珍しくなってしまったHTMLレベルで管理するwebページを提供しているのは、自分のデータはなるべく自分でコントロールしたいという思想から発生しているものです。
Qiitaが信用できなくなったからZennやはてなブログに記事を移動させたとかいうページを見るたびに、 Zennが今後Qiitaのようにならないと思う確信はどこから来るんだろうなと思います。
確かにQiitaのやらかしは擁護できないものですが。
- Qiita、読んだ記事の傾向を合意無しに表示して炎上 批判受け機能停止中 - ITmedia NEWS
- 「さくらのレンタルサーバ」批判記事、Qiitaで公開止められ炎上 さくらは「事実確認中」 - ITmedia NEWS
しかし今回これはGitHubにデータを保存して使っているので既にGitHubに依存してしまっています。それならZennのスクラップを使っても良かったのではないかと少し思いました。依存先を減らすのは意味があるかもしれませんが。
単純なgh issue viewだと微妙なフォーマットをかけられてしまいます
例えば、 descriptionもGoogle任せではなく設定する · Issue #155 · ncaq/www.ncaq.net を閲覧してみます。
2023-08-10T17:42:19 ⬢ [Systemd] ❯ gh issue view https://github.com/ncaq/www.ncaq.net/issues/155
descriptionもGoogle任せではなく設定する #155
Closed • ncaq opened about 5 months ago • 2 comments
Labels: Estimate: 2, Priority: Low, Type: Bug, Type: Feature
自動解析されてfooterを出されることが増えてきた
———————— Not showing 1 comment ————————
ncaq (Owner) • Mar 4, 2023 • Edited • Newest comment
適当に100でええか
Use --comments to view the full conversation
View this issue on GitHub: https://github.com/ncaq/www.ncaq.net/issues/155
Markdown形式で記事化したりDeepLに投げ込むにはこれでは不向きですね。余計なメタデータが多すぎることと、せっかく元がMarkdown形式であるにも関わらず中途半端にフォーマットされてしまっています。
--templateフラグを使って制御しようかとも思いましたが、どちらかと言うとこれはメタデータをフォーマットするためのフラグであることと、
Markdown文法に対して一つずつ対応させるのが面倒です。元がMarkdown形式なので生の情報を取れれば十分なわけです。
--jsonフラグでJSON形式でほぼ生のデータを取れて、
jqのコマンドを使ってフォーマット出来るようなので、その方針で実装しました。
gh-issue-exportコマンド
gh-issue-exportコマンドとして置いています。
#!/bin/zsh
set -eu
gh issue view $@ --json author --json createdAt --json body --json comments \
--jq '{
top_level: ("@" + .author.login + " " + (.createdAt|fromdate|strflocaltime("%Y-%m-%dT%H:%M:%S %Z")) + "\n\n" + .body),
comments: [.comments[] | "@" + .author.login + " " + (.createdAt|fromdate|strflocaltime("%Y-%m-%dT%H:%M:%S %Z")) + "\n\n" + .body]
} |
.top_level + "\n\n---\n\n" + (.comments | join("\n\n---\n\n"))' | \
tr -d '\r'
--jsonと--jqで本文とコメントとその本文を全て取得して、投稿者と時間と本文を出力しています。そのままだと投稿間の区切りが分かりにくいため、
---で投稿を区切るようにしています。また改行がCRLF形式になってしまう部分があるためtrコマンドでCR部分を除去しています。
例えば先程の、 descriptionもGoogle任せではなく設定する · Issue #155 · ncaq/www.ncaq.net の例で実行すると以下のように出力されます。
2023-08-10T17:45:57 ⬢ [Systemd] ❯ gh-issue-export https://github.com/ncaq/www.ncaq.net/issues/155
@ncaq 2023-02-20T02:53:17 JST
自動解析されてfooterを出されることが増えてきた
---
@ncaq 2023-03-04T19:07:59 JST
長さは少し切り詰めたほうが良さそう
---
@ncaq 2023-03-04T19:07:59 JST
適当に100でええか
最初は以下のシンプルなものを使っていましたが、
DeepLに放り込むと投稿者が分からないと困ると気がついたため、そちらはgh-issue-export-only-bodyコマンドとして分けることにしました。
#!/bin/zsh
set -eu
gh issue view $@ --json body --jq '.body' --json comments --jq '.body, .comments.[].body|., "\n---\n"'|tr -d '\r'
クリップボードにコピーしたい時はXSelを使った、以下のto-clipboardエイリアスにパイプで流し込みます。
alias to-clipboard='xsel --logfile /dev/null --input --clipboard'
hatena-bookmark