Integromat GitHubのファイル更新

IntegromatGitHubのファイル更新

Integromatのwebhookへpostを投げて, GitHubの既存ファイルを更新する.

正直, 記事にすることでもないと言えばそのとおりだし, どうせQiitaで検索でもかければ十分量の情報は手に入るだろう. ただ, どうやらZenn上ではまだIntegromatの記事が少ないみたいだから, その肥やしにでもなればと思う.

Integromatとは

IFTT, Zapierとおなじくサービス連携サービスである. Integromat は両者に比べれば, 遥かに自由度が高いことが特徴だろうか. 反面, もはやノーコードとは言えないだろう.

結果

Scenarioは3モジュールで構成される. それぞれのモジュールは1オペレーション分しか動作しない. 月あたりでは単純にWebhookが入ってきた回数かける3回のオペレーションを消費する.

Webhookモジュール

Webhookの設定. とはいうもののScenarioから用意することはない. webhookの作成時に次のように一旦そのurlへアクセスすることを要求されるので, ブラウザの別タブでも開いて "Accept" させる. jsonデータ構造は後から設定することもできる.

jsonデータ構造は "url", "title", "date", "expr"とした. "expr" にはいわゆる説明が入ることになる.

GitHub get a file モジュール

画像ではFilePathのファイル名が間違っているが, 要はRepositoryのファイル名を指定すれば良い.

なお, 本来ならファイル名は .tsv , tab separate valueにするつもりだった.

GitHub create and edit モジュール

このScenarioにおける肝である. File PathやSHAに直前のGithub get a fileで獲得したSHAを指定することで, 既存ファイル更新ができる. Messageはgitのコミットメッセージになる.

Dataがファイル内容となる. 先のFile PathやSHAと同じようにまずはGithu get a fileで獲得したDataを入れ込むのだが, 一旦toStringで後続の形式と合わせた. Dataを忘れれば当然内容を失う. 形式はもしかしたら合わせなくてもよしなにしてくれる可能性はあるが, 単位の次元を合わせて計算するのと同じように, 型を合わせたほうが事故が少ない.

さて, Dataの終端はWebhookで送られてきたjsonデータの追記が来る. 私はこのファイルを次のレコード形式で保管しているため, それを作る. このとき,titleとexprにはタブ文字が含まれていることがありうるのでreplaceでspaceに置き換えている. これでタブ区切りファイルとできるから, shell scriptで加工がしやすい.

<date>\t<title>\t<url>\t<expr>\n

動機

もともと, こんな感じでのBookmark保存にはPocketを利用していた. しかし, 個人的に管理(というか利用していた)アカウントをリストラしていきたい欲求があった. その中でPocketがそのリストラ対象になったことがきっかけである.

私がPoketに求めていた機能はそのBookmarkの一元管理であった. 別段Discoveryやカテゴリー分けも求めていなかった. したがって, 以下が満たされれば十分Pocketのアカウント削除は可能と考えそれを実施した.

• Bookmarkの一元保存空間 :: 今回はこれをGitHub上に逃がすことで達成.
• Bookmarkの一元保存行為 :: 今回はIntegromatへのPOSTで達成. なお, POSTすることはchrome extensionを自作した.

可用性

一般的な目線で言えば, 低いと言わざるをえないだろう. 理由は次による.

• 追加でいちいちgitを操作される.
• 削除はいちいちgitを手動で更新する形で行う.
• Bookmarkしたページへの訪問を対象ファイルからurlを持ってきて行わないといけない.

しかし, これらは私主観的な目線ではデメリットにならない. それは次の理由と運用による.

• そもそも, 個人利用Repositoryへの操作であり, 追加でどれだけ操作されようともたかが1ファイルへの操作であり, 変更衝突や他者への気遣いなど必要がない.
• 対象url訪問や削除を行う時とは, つまり, それらを何か自分を対象読者とする記事にまとめる時であり, それが簡単な行為になる必要は薄い.
  • 記事を記述することが遥かに時間のかかる行為であり, urlをコピペすることなど誤差時間でしかない.
  • ファイルとしてまとまっていれば, grepである程度絞り込みが可能であり, その際にMarkdownリンクにでも整形しながら出力すれば, そもそもコピペもしない.

したがって, 個人的には十分な利用価値を担保することができた.

改善点

以下の改善事項がある. しかし, 個人利用のため気づいたときに手動で治せるのでもっと大規模にならない限りはあまり対処する気にならない.

• タブ区切りファイルとするためにタブを置き換えているが, きちんとケースを考えると, 他の記号類も置き換えしないとならない.
• POSTされたらそれを追加するため, 容易にurlが重複する.