ひと夏の技術

つかいかた

リポジトリのREADMEちゃんと書いた(つもり)なので読んで設定すればOKなはず。

GitHub ActionsのJobとかの設定と、当該アクション(Auto-Card-Assign)固有のアサインconfigを用意する必要がある。

configはプロジェクト名+カラム名+カラムごとにアサインしたいメンバーを書くという具合。

kanban1: # Project name To do: # Column name - "memberName1" # Login name(assignee name) In progress: - "memberName2" Review in progress: - "memberName3" Reviewer approved: - "memberName1" - "memberName2" - "memberName3" Done: []

こういう感じ

『このカラムに動かしたらアサインを全部外したい』という場合は空配列[]にする。

カードを移動してもなにもしたくないカラムの場合は設定に書かなければOK。移動先カラムがconfigに設定されてなければ処理はスキップされるようになっている。

よもやま話

そもそもなんで作ったかというとこのActionsのニーズがあった＋GitHub Actions触ってなんかやらないとなんもわからんなってことでちょうど題材があったこいつをつくった。

カンバン運用していてカードを別カラムへ移動させたらアサインを変えたいケースがあって、毎回移動させてからIssueやPRを開いて手でちまちまアサインを変えていてつらかったのでなんとかしたかった。探してもなぜか意外とありそうでなかったのでつくった。なかったということはそもそも世間では需要がないということなのかもしれない。

稼働コストとしてはv1ではだいたい1カードあたり平均15秒くらいで終わる。1分間で4カードさばける計算。GitHub Actionsはフリープランでは2000min/1monthだから、めちゃくちゃ単純に考えると8000回/月は発火できる計算になる。よほど活発でなければ1ヶ月にそんなには発火しないだろうからまあ大丈夫だろうと思っている。

実装のはなしをすると、GitHub API叩くところはv3のRESTじゃなくv4のGraphQLを使っている。ちょうどやりたいことを実現するためのAPIがv4のほうにいい感じに生えてたというのもある。ただ、実装はじめてから気づいたけど、サーバーサイドでGraphQL叩くとTSの型が推論できなくて無理やりオレオレ型書いて解決するしかなかった。クライアントサイドならApolloに乗っかればいいのだけど、サーバーサイドNode.jsだとなんかいい感じのライブラリがなくて諦めた。そもそもサーバーサイドからGraphQLのAPIを叩くんじゃあないよという話かもしれない。

タイトルどおり。アプリケーションでエラーが出た場合にSentryにエラーレポートを飛ばしていたのだけど、送信する手前でなんかごにょごにょやりたくなったので調べた。

beforeSend

Sentryのドキュメント、ものすごく目的のものを見つけづらい。

docs.sentry.io

やりたいことはこのDocsに書いてあるとおりで、Sentry.initする際の引数のオブジェクトにbeforeSendがある。

import * as Sentry from '@sentry/browser';

Sentry.init({
  beforeSend(event, hint) {
    console.log(event);
    console.log(hint);
    return event;
  }
});

eventはSentryに送られるレポートのデータが入っている。idとかデバイス名とかなんやかんや色々。ようはレポート上で見れるデータがこれ。

hintは発生したオリジナルのエラーexception。

beforeSend関数で返したeventオブジェクトが最終的なSentryレポートになって、nullを返すとこのエラーレポートは破棄される。

なにをやりたかったか

Sentryに追加で送信する任意のデータの枠にextraという概念がある。Sentry.setExtraあるいはSentry.setExtrasでセットできる。

docs.sentry.io

で、ここにバンバン必要なレポートデータを詰めていくと便利なのだけど、Sentryは1レポート200KBの制限があってこれを超過するとエラーレポート自体が送信されないという問題がある(つまりエラーが起こったことがわからない)。厳密にはSentry側が課している成約というよりはFetchとブラウザの仕様らしい。

エラーデータは動的なのでケースバイケースで200KB超過してしまってエラーレポートがもみ消されたりしていては困るので、Sentryに送信する前にデータサイズを見て、データをなんとかして200KB以下に抑えたかった。

Reduxのトラッキングを送信するケース

具体的にextraになにを入れたかったかというと、Reduxのstateの一部だったりdispatchされたactionをレポートに添えたかったというニーズがあった。

github.com

これはRedux middlewareのライブラリで、ReduxサイクルのトラッキングをしてSentryのextraにReduxの操作を突っ込んでくれる便利なライブラリ。

外部依存モジュールなしの素朴なjsファイル1枚だけのmiddlewareなのだけど、自前で用意するよりうまくできているので、これを突っ込んでおくだけでいい感じにReduxのトラッキングをしてくれて便利。

ただSentryのドキュメントで「stateは大きいかもしれんからextraに突っ込むなら気をつけて」的な言い回しがあり、実際このライブラリを使うとケースによっては200KBを超えていく可能性がある。

そういうわけで前述beforeSendで200KB超えた場合の処理をしたかったという経緯がある。

ちなみにサイズを測るには

beforeSendでサイズを見るには第1引数のeventのサイズを見ればよくて、npmライブラリだとこの辺が使えると思う。

www.npmjs.com

200KB=200000byteなので、200000byteを超えてたら諦めてよさそうなデータを削るとかそういう作戦をとれる。

ようはbeforeSendでSentryに送信されるレポートデータを加工したりできて、いい感じにやれるというはなし。

ひと夏の技術

GitHub Projectのカンバンでカードのアサインを自動で変えるGitHub Actionをつくった

GitHub Actions Auto-Card-Assign

様子