GitHub ActionsでのJestのテスト実行時に失敗箇所をPRへのアノテーションとして表示するレポーター

このような便利なパッケージがありました。

GitHub Actionsにはworkflow commandsと呼ばれる、echoコマンドと特定の形式の文字列を使うことでActionsの処理に一部介入できる機能があります。その中にはファイルの特定の箇所(行・カラム)にdebug/warning/errorメッセージをPRのアノテーションとして追加できるコマンドがあります。jest-github-actions-reporterではJestのレポーターの実装としてそのSetting an error messageコマンドを使い、Jestのテストの失敗結果をerrorアノテーションとしてPRの差分表示上で簡単に結果が閲覧できるようになっています。

こういうやり方があるのはRenovateのこのPRで気付きました。

きっとそのためのJestのレポーターをパッケージとして作成・公開している人がいるだろうと探してみたら、案の定存在した次第です。

GitHub Actionsで日々の暮らしを楽にしていきましょう。

AndroidのFirebase Installations version 16.2.0で追加されたlintチェックがAndroid Gradle plugin 3.6と互換性がなくてビルドできない

Firebase OSSのこちらのIssueで報告されているように、Android Gradle plugin 3.6(Android Studio 3.6)以上のプロジェクトでFirebase Installations version 16.2.0が依存性に入るとlintでビルドが失敗するようになります。

追加されたlintというのはこちら:

https://firebase.google.com/support/release-notes/android?hl=ja#installations_v16-2-0

Added a lint check to the compile process that prevents parallel usage of Firebase installations and incompatible versions of the Firebase Instance ID SDK that are older than firebase-iid:20.1.0. Firebase installations creates FIDs as Firebase client identifiers. Versions of the Firebase Instance ID SDK before v20.1.0 created different Firebase client identifiers: Instance IDs. This check prevents problems for Firebase targeting that might be caused by conflicting Firebase client identifiers.

数時間前にはこの問題を修正するPRがマージされたので、近々修正されたバージョンがリリースされるはずです。しばらく待ちましょう。

待てずにすぐFirebaseの各種バージョンを上げたい場合は、Issueにあるように該当のlintを無効にすることでひとまず回避することができます。

android {
    lintOptions {
        disable "IncompatibleIidVersion"
    }
}

Swift 5.2

iOS 13.4とXcode 11.4と共にSwift 5.2がリリースされましたね。

Swift.org - Swift 5.2 Released!

  • SE-0249 Key Path Expressions as Functions
  • SE-0253 Callable values of user-defined nominal types
    • SE-0216@dynamicCallableに対してstatic callableとも呼ばれた機能。callAsFunctionというメソッドを定義することで、型や値を直接関数のように実行することができる。
  • Improved Compiler Diagnostics
  • Code Completion Improvements
    • コード補完の改善
  • Improved Build Algorithms
    • 主にインクリメンタルビルドの速度の改善
  • Debugger Improvements
  • Swift Package Manager
    • 依存パッケージがSwift 5.2のパッケージ定義を使っている場合、その依存パッケージのテストターゲットでしか使われていない孫依存パッケージは利用元のプロジェクトでは解決されなくなる(不要なtransitive dependencies:推移的依存性がなくなる)
  • SwiftSyntax Updates
    • ノード階層がprotocolベースからstructベースになったことによる速度改善
  • Language Server Protocol Updates
    • sourcekit-lspというLSPのランゲージサーバーがXcodeとCommand Line Toolsに同梱されるようになった
    • FixItsとLocal Refactoringのサポート追加

というラインナップになっています。今日から早速どんどん活用していきましょう! ⚡️

OkHttp 4.xと3.xでのバイナリ非互換の事例

GitHub Actionsのcheckoutアクションがv2でいろいろ変わって便利になっていた

GitHub Actionsをそこそこ使っている今日この頃です。さて、Actionsといえば普遍的に使う、リポジトリをチェックアウトする actions/checkout がありますが、このアクションがv2になり、色々と挙動が変更・改善されてい便利そうなのでいくつかご紹介。


  • fetchのdepthがデフォルトで1になり、フェッチが速くなった
  • チェックアウトの際に使用されたActions発行のトークンがgitのconfigに永続化され、リモートへのpushなどの操作が設定要らずでできるようになった
  • ブランチのチェックアウト時にはローカルブランチを作るようになった(detached HEADにならない)
  • チェックアウト先のパスを指定する path設定が絶対パスではなく $GITHUB_WORKSPACE 基準の相対パスになった

特に1〜3つ目は細かい困りごと・面倒ポイントを潰してくれていて好印象です。アクションの新バージョンには気づきにくいですが、どんどんアップデートして便利に使っていきたいですね。

追記

submoduleのチェックアウトが逆にv2では現在サポートされていないということなので、手でやる必要があり要注意です。この手段もSSHでは動かないとかもあり、submoduleを使っている方はしばらくv1の方がいいかもしれません。

https://github.com/actions/checkout#checkout-submodules

- uses: actions/checkout@v2
- name: Checkout submodules
  shell: bash
  run: |
    auth_header="$(git config --local --get http.https://github.com/.extraheader)"
    git submodule sync --recursive
    git -c "http.extraheader=$auth_header" -c protocol.version=2 submodule update --init --force --recursive --depth=1

和暦と改元とうるう年が組み合わさったバグの思い出

あけましておめでとうございます。新年一発目の投稿は2019年の思い出です。

ということで本年もよろしくお願いします 🙏

2019年のSwiftモック事情

こんにちは、id:ikesyoです。これは はてなエンジニア Advent Calendar 2019 17日目のエントリーです。


昨日12月16日(月)に行われた 年末だよ Android/iOS Test Night - 2019 にて、『2019年のSwiftモック事情』という発表をしました。

Swiftでテストのためのモックを用意するとなると、リフレクションでめちゃくちゃするということができないので、素朴に手で書くか、コード生成をすることになります。今回の発表ではコード生成に主眼を置き、以下の4つの選択肢を紹介しました。

それぞれの機能や違いなど詳しい内容は、ぜひ発表のスライドを見てみてください。

Swiftでのモック事情については、今年4月の Mobile Act KYOTO #1 でも発表をしていました。

しかしこの後の8ヶ月で意外と状況が変わっており、その差分を今回の発表に入れ込んでいます。

  • SwiftyMockyの設定ファイルとコマンドが変わった
    • Before: 設定ファイルはmocky.yml、コマンドはsourceryを直接利用
    • After: 設定ファイルはMockfile、コマンドはswiftymockyという専用のものが用意された(Sourceryの存在をラップ・隠蔽)
  • Cuckooの機能追加
  • Mockoloの発表とリリース
    • Uber製のモックジェネレーターで、コード生成が高速であるのが売り
    • 5月に開催されたUIKonf 2019での発表で公表され、OSSとしてリリース予定とされていた
    • 9月に1.0.0がリリースされた

Mockoloについては、UIKonfのセッション動画が公開されており、開発者自ら独自のジェネレーターを作るに至った背景や、高速化のためにやったことを丁寧に説明してくれています。こちらもぜひ見ましょう!

ということで、2019年末時点でのSwiftのモック事情をご紹介しました。どのツールを使うかは、

  • 機能
  • APIの好み
  • チームメンバーの規模や習熟度
  • プロジェクト(コードベース)の規模

など複数の要素に影響されると思います。ぜひ自分たちに適した選択肢を導入してみて、Swiftのテストライフを豊かなものにしていきましょう! 🤖


あわせて読みたい