GitHub Actionsでカバレッジを可視化する
モチベーション 今携わっているプロダクトは、DDD+Clean Architectureなマイクロサービスとして構築しています。 自身の担当業務としてはレセプト関係になります。業務の特性上、複雑なビジネスルールをきっちりかっちり作らないといけないのでテストはかなり重点的に書いています。 ビジネスルール、ユースケースといったレイヤー化されたクラスにそれぞれテストを書いていくわけですが、ユースケースが依存しているビジネスルールが一つの場合など、いちいちユースケース単体でテストを書くのか？ということもあり、ケースによりますがテスト粒度を上げるという判断もしてたりします。 テストコーディング時に依存性を排除する為にモックを大量に使いますが、上記のような判断があったり、なかったりするとテストのカバー範囲の認識齟齬というものが出てきて最終的にカバレッジが漏れる事案が発生します。 またPRレビュー時にテ
GitHub Actions で SSH デバッグ！ (debugging-with-tmate)
tl;dr 失敗したステップの次に #スニペット を貼って workflow 発火します。おわり！ 導入 みなさん、GitHub Actions 使っていますか。他 CI サービスと比べていくつか機能が間に合ってなくて移行できない、みたいな人たちも結構いるんじゃないかと思います。今回は Circle CI などではできていた SSH デバッグができるよさそうな Actions をみつけたので、その方法を紹介しようと思います。（技術的には昔からできたが、その決定的な方法がなかった。） 今回紹介する Actions は debugging-with-tmate です。以下ではそのおすすめの使い方を紹介します。 SSH デバッグのおすすめ手順 あるブランチでの、ある workflow のある step が失敗した そのブランチからデバッグ用のブランチを切る その step の次に debuggi
GitHub Apps経由で発行したtokenを用いて、GitHub Actionsで使う
モチベーション github action で、secrets.GITHUB_TOKEN の権限を超えて GitHub を操作する場合、Personal Access Token を使って操作することが多い。 Personal Access Token はセキュリティの都合上、有効期限を設定することがベターとされており、無期限で作成したくない。 個人で管理する repo などであれば ↑ でも問題ないが、Organization で複数人が管理する場合、個人の Access Token を使うことはそもそも避けたい。 GitHub Apps を用いてチーム管理 Token を払い出す（意訳）ことで、Personal Access Token に依存せずに、secrets.GITHUB_TOKEN の権限を超えて GitHub を操作できるようにする。 ゴール Organization 配下
GitHub署名付きでコミットしてかっこつける
署名とは このようにVertifiedと書かれたコミットを見たことがありませんか？ かっこよ！！！ 調べてみると公式のヘルプページにはこう書かれていました GPG あるいは S/MIME を使って、タグやコミットにローカルで署名できます。 それらのタグやコミットは検証済みとして GitHub上でマークされ、他の人々がその変更が信頼できるソースから来たものと信頼できるようになります。 つまり、「これは信頼できるコミットだよ」って表現することができるということですね。（かっこつけるためではないようです）と そもそも、署名を行わない場合GitHub側でクライアントとGitHubアカウントとの紐付けをメールアドレスの一致のみで行います。もし、Gitに他人のメールアドレスを設定した場合そのメールアドレスを持ったGitHubアカウントと紐付けられます。 ここで、自分のアカウントと署名を紐付けることで自
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
