nashcft's blog

時々何か書く。

Android: アプリからメールアプリを開く時の Intent の設定とメールアプリの挙動について

以下の tweet に関する話。

発端

開発中のアプリでアプリ内から件名や本文テンプレート入りのメールを送る機能を実装して人に見てもらったら件名と本文が出ないんだけどって報告が来て、調べてみると件名や本文が送る内容によって出たり出なかったりした。あと報告で使われてたアプリが Gmail だったのだけど Outlook で開いてみたらどのメールもちゃんと件名と本文が反映されてることがわかった。

その時のコードの雰囲気と挙動

大雑把に問題の箇所を取り出すと以下のような感じ:

fun createEmail() {
  startActivity(createMailToIntent(address, subject, text))
}

fun createMailToIntent(
  address: String?,
  subject: String,
  text: String
): Intent {
  val intent = Intent(Intent.ACTION_SENDTO, Uri.parse("mailto:${address ?: ""}")).apply {
    putExtra(Intent.EXTRA_SUBJECT, subject)
    putExtra(Intent.EXTRA_TEXT, text)
    flags = Intent.FLAG_ACTIVITY_NEW_TASK
  }
  return Intent.createChooser(intent, "Select an app."))
}

作成するメールの種類と Gmail, Outlook の挙動を確認すると、送信先メールアドレスの有無が関係しているようだった:

  • メールアドレスなし
    • Gmail -> 件名・本文が反映される
    • Outlook -> 件名・本文が反映される
  • メールアドレスあり
    • Gmail -> 件名・本文が反映されない
    • Outlook -> 件名・本文が反映される

調べてわかったこと

Gmail では Intent に与える data (URI) の mailto: の後にメールアドレスが続くと、 extra で指定したパラメータを無視するという挙動をとるらしいことがわかった。そこで、data ではメールアドレスを指定せず mailto: のみとし、かわりに Intent がデフォルトで持っている key の一つである EXTRA_EMAIL送信先を指定するようにしたところ、 Gmail でも送信先、件名、本文全てを作成するメールに反映してくれるようになった。

developer.android.com

この設定で Outlook を選択しても同様に送信先と件名、本文を反映してくれたので、今回はとりあえず extra で指定する方法に修正することにした。

この後ちょっと気になってURIと extra の両方でメールアドレスを設定したときに Outlook はどう処理するのかというのを試してみたところ全部作成メールに反映してくれた。なのでこの場合 mailto: の後のアドレスと EXTRA_EMAIL で指定したアドレスの2つが to: に入力されてしまい、まあ意図的にこういう送信先設定はしないよねということで使い道はなさそう。

修正後のコード

fun createEmail() {
  startActivity(createMailToIntent(address, subject, text))
}

fun createMailToIntent(
  address: String?,
  subject: String,
  text: String
): Intent {
  val intent = Intent(Intent.ACTION_SENDTO, Uri.parse("mailto:")).apply {
    putExtra(Intent.EXTRA_EMAIL, arrayOf(address ?: ""))
    putExtra(Intent.EXTRA_SUBJECT, subject)
    putExtra(Intent.EXTRA_TEXT, text)
    flags = Intent.FLAG_ACTIVITY_NEW_TASK
  }
  return Intent.createChooser(intent, "Select an app."))
}

おわりに

ここまで書いてから Android Developer 見に行ったら普通にこう書けよって解説あったのでちゃんとリファレンス読んで実装しようねってなった。

developer.android.com

それはそうと挙動確認用のサンプルコードがあるので、GmailOutlook 以外のメールアプリを使用した場合の挙動はどうなるの? というのが気になったらお使いください。

github.com

Bitrise で Android instrumentation test を実行させるための調査メモ

最近 Android アプリの instrumentation test を実行する workflow を構築する機会があったので、そのために当たった情報やついでに気になって調べたことなどを覚書も兼ねて記事にすることにした。

目次

Steps

必要なのは以下の2つ:

基本的に何を設定すればいいかは公式のドキュメントを読んで組み立てればOK。

devcenter.bitrise.io

Virtual Device Testing for Android で instrumentation test の設定をする

実行するテストを指定する

Workflow Editor の Virtual Device Testing for Android には Instrumentation Test というセクションがあって、 instrumentation test のための設定がいくつか行える。開くと以下のキャプチャのような感じ。

f:id:nashcft:20191207193823p:plain

この中の Test targets, seperated with the "," character. という項目で実行するテストを指定することができる。指定の方法は3種類あって、editor の記述を持ってくると

  • package package_name
  • class package_name.class_name
  • class package_name.class_name#method_name

というようにパッケージ単位から特定のテストメソッドまで指定することができる。上のキャプチャではクラス単位での指定をしているが、例えばパッケージでまとめるなら package jp.nashcft.uitest.example 、テストケース単位だったら class jp.nashcft.uitest.example.UITest1#fooTest というようにすれば良い。

これによって特定の文脈では一部のテストだけ実行する、みたいなことができ、例えば Room のスキーマを変更する際に特別な branch 名を使うようにして、その branch に対する workflow では migration test だけを実行対象にした instrumentation test の step を設定する、といったことが考えられる。

また、項目名にあるように、複数の実行対象を指定する場合は , で区切れば良い。これにはちょっとした罠があって、多数指定する場合、可読性のために改行を挟みたくなることがあると思うが、, の後に改行を入れてしまうと最後の行で指定された対象以外は実行対象として認識されなくなってしまう。なので、一切改行を入れずに羅列するか、どうしても改行したい場合は classpackage の後の whitespace で改行すると全ての対象を認識してくれるので、そのように回避する必要がある。とはいえ Workflow Editor 空記入するにしても bitrise.yml に直接書き込むにしてもどうせコピペ運用になると思うのでそこまで気にしなくても良いかもしれない。余談だが、この挙動について認識しているのか editor で改行せず実行対象を羅列して保存し、 bitrise.yml を見ると、class / package の後で改行しながらの記述になっている。

Test Reports で実行結果を見る

Test Reports そのものについては公式のドキュメントがあるのでそちらを参照してほしい。

devcenter.bitrise.io

Test Reports で確認できるものは、各テストケースの実行結果の他に、テスト実行時の録画やスクリーンショット、ログ、CPU/RAM/Network のプロファイルなどがある。

ところで今回構築していた時に気づいて確認したことだが、Virtual Device Testing for Android を使用した場合、そのあとで Deploy to Bitrise.io を実行しなくても Test Reports に実行結果がアップロードされている。内容的に先に UI testing のページを読んでいた場合には別に当然という認識になるのだが、私は以前 Test Reports の方だけ調べていた時期があって、そちらのページには (今でも) test step 実行後に Deploy to Bitrise.io を実行すると結果をアップロードしてくれると書いてあったので、deploy 忘れてるのに Test Reports が見られたので少し驚いてしまった。

既知の問題

Android library の AndroidTest build が失敗する

Android library は assemble すると aar を生成するが、 Android Build for UI Testing は成果物に apk だけを想定しているため、 step が失敗してしまう、という issue があがっている。

github.com

こちらに関しては Bitrise の中の人に認知されていて、 forum の方で feature request が作成されている。この feature request は vote の数が多くなると priority の高い項目として対応されやすくなるので、関心のある人や対応されないと困るなあという人はログインしてこの request に vote しておくと良い。

discuss.bitrise.io

現状でなんとか Android library の instrumentation test を実行したいという場合は、多分 script step で自分でコマンド指定してビルドして、成果物の出力先パスを Virtual Device Testing for AndroidApp pathTest APK path に渡せば動くかもしれない。これはまだ試していないので実行できるかは不明。

Nested module はビルド対象として認識されない

これは Android 系 build step 共通の問題なのだが、現状 project の root directory にある module しかビルド対象として認識されず、存在しない module を指定しているとしてビルドが失敗する。

例えば以下のような project があるとする:

/
+ app
|  + build.gradle
+ features
  + featureA
  |  + build.gradle
  + featureB
     + build.gradle

この場合、step に認識される module は app だけで、 feature ディレクトリ以下の各 module は検出されない。

この問題については原因となるパッケージに対して既に修正のPR が出されていて merge もされており、これに依存している各 step のレポジトリも依存を更新しているので、次回のバージョンアップで解決するはず。

調べてないこと

  • Instrumentation test の設定の Use Orchestrator って何
    • 多分以下のドキュメントに書いてある設定のことだと思うけど、外部から設定できるんだなって

developer.android.com

先の話、願望の話

前述した nested module を認識しない問題と Android Build for UI Testing (と、もしかしたら Virtual Device Testing for Android も) の aar 対応がリリースされたら feature module などの instrumentation test 用 workflow を構築するつもりだ。これについて既に見えている課題として、

  • それぞれ 1 step あたり1つの module しか対象にできない
  • 現状 Virtual Device Testing for Android が1ビルドあたり1 step しか設定できない

というのがある。これらを解決する一番単純な方法は対象となる module の分だけ workflow を作って Bitrise Start Build で並列化して繋いで実行するという感じになるが、数個だけならまだやるとしても既に数十個の module に分割されているアプリに対してそれをするのは作業する気にもなれないし、仮にやったとして、1回実行しただけで queue がパンクするんだよなあ... となる。Queue の方は per concurrency plan から Pay as You Go plan に変更すれば一応解決するが、財力の問題が当然ある。

まあ Pay as You Go plan にするにしてもそうでないにしても、こういう方針でやるなら全ての module に対してまとめてビルドを行って、artifact をテスト実行コンテナにバラバラっと配って、そちらでそれぞれの module の instrumentation test を実行する、というような構成ができたら総ビルド時間も短くなるし嬉しいんだよなという思いがある。これは実質 CircleCI の workflow による job の pipeline 化と1つの workflow 内での workspace の共有と同じような発想なのだけど、Bitrise でも build router start で workflow の並列実行ができるようになっているのだしこういうことが Bitrise でもできるようになってほしいなあって期待してる。

circleci.com

もしくは Android Build for UI Testing が variant だけ適当に指定したらそれにヒットする module のビルドを行ってくれるようになって、Virtual Device Testing for Android が複数のテスト対象を 1 step でまとめて実行してくれるようになってくれたら、というアイデアもある。こっちの方がユーザ的にはやることが少なくなって楽だけど、任意の数の module に対して成果物を取得してそれぞれに対して Firebase Test Lab (もしくは何らかの device farm) でテストを実行して結果を収集して Test Reports にアップロードするというのを実現するのはしんどそうだなあと思う。

終わりに

Android の instrumentation に必要な2つの step は、Android Build for UI Testing は v0.1.1, Virtual Device Testing for Android は step 名に [BETA] とついていることから察せるようにまだ発展途上というか機能的に物足りなく、単純に apk のテストをすることしかできないが、単にいくつかの設定を記入するだけでUIテストを実行してくれる手段を公式で提供してくれているというのは他のCIサービスにはない強みだと思うので、今後のバージョンアップに期待したい。

参考資料

Deploy to Bitrise.io で生成した artifact のインストールページの QR code を作る

社内に需要があったので

調べればこれについて言及のある記事がいくつも出てくるけど、だいたいが一連のビルドフローに関する解説記事の一部で触れられているという感じで目的の情報に辿り着くのが手間な状況なので QR code だけにフォーカスした記事を作ろうという動機で書いている。

手順は大まかに以下の2 (or 3) ステップ:

  1. Deploy to Bitrise.io で public install page を生成
  2. Create install page QR code で 1. で作ったページのURLの QR code を生成
  3. QR code の画像URL $BITRISE_PUBLIC_INSTALL_PAGE_QR_CODE_IMAGE_URL を任意の用途に使用する

Deploy to Bitrise.io で public install page を生成

Workflow Editor でいうと "Enable public page for the App?", bitrise.yml でいうと is_enable_public_pagetrue にする。1.6.0 現在 default true なので、自分で false にしてあるのでなければそこの設定をいじる必要はなし。

Create install page QR code で public install page URL の QR code を生成する

github.com

これ

生成対象が default で $BITRISE_PUBLIC_INSTALL_PAGE_URL になってるので追加するだけで良い。必要であればお好みで生成される画像のサイズを調節することができる。

生成された QR code を使う

上記のステップによって $BITRISE_PUBLIC_INSTALL_PAGE_QR_CODE_IMAGE_URLQR code の画像URLが設定されるので適当に使えばOK。例えば Slack にビルド結果を通知しているのであれば、 "A URL to an image file that will be displayed inside the attachment" (image_url) にこの環境変数を設定すれば通知されたメッセージに QR code が表示されるようになる。

bitrise.yml

- deploy-to-bitrise-io:
    inputs:
    - deploy_path: "<path to your artifact>"
- create-install-page-qr-code: {}
# Slack 通知で使う場合
- slack:
    inputs:
    # other configurations...
    - image_url: "$BITRISE_PUBLIC_INSTALL_PAGE_QR_CODE_IMAGE_URL"

Bitrise Test Reports について調べてみた記録

先週 Bitrise の build log に "Test Reports" って項目が増えてて、JUnit とかのテスト結果をアップロードしたらGUIでいい感じにみられるようにしてくれる機能が追加されたことを知った。公式のドキュメントを読んだ感じだと Bitrise から提供されてるいくつかの test step の後に Deploy to Bitrise.io 使ったらアップロードされるよと書いてある他に、対応しているファイル形式についても書いてあった。それによると plistJUnit XML に対応しているとのことで、じゃあアップロードの仕組みがわかれば指定されてる test step を使わなくてもできるのでは、と思って色々試したり step のコードを読んだ結果として面倒くさくなって諦めたことについて書き残しておく。

ドキュメントを読んでやってみたこと

私が今 Android アプリ開発をやっているということで読んだのは以下2つ:

特に2つ目の以下の記述について注目した:

You can check your Android unit test results on the Test Reports page. The Android Unit Test Step generates and exports unit test reports into the $BITRISE_TEST_DEPLOY_DIR folder. Then the Deploy to Bitrise.io Step exports those reports from the $BITRISE_TEST_DEPLOY_DIR folder to the respective build’s Test Reports page where you can view the test results.

ここの記述から $BITRISE_TEST_DEPLOY_DIR にテスト結果 (<module>/build/test-results) を放り込んだらアップロードできるのではと考えて適当にテスト結果をコピーしてみたところ、何もアップロードされず Test Reports には何も記録されなかった。

コードを読んでわかったこと

どうもファイルがあれば良いという単純な話ではなさそうなので、Test Reports へのアップロードを担当している Deploy to Bitrise.io step と、テスト結果の収集方法についての参考に Android Unit Test step のコードを追ってみた。

github.com

github.com

Deploy to Bitrise.io の方は、まず main.go の以下の部分が対応している:

https://github.com/bitrise-steplib/steps-deploy-to-bitrise-io/blob/f1ce02dacdb35d56c05b3e6fc1522ad53828ca33/main.go#L229-L246

config.TestDeployDir$BITRISE_TEST_DEPLOY_DIR を指しているのでそこに対象のテスト結果を配置することは間違っていないようだ。なので、test.ParseTestResults が何をしているか紐解く必要がある。これは repository の test/test.go に記述されている。

https://github.com/bitrise-steplib/steps-deploy-to-bitrise-io/blob/f1ce02dacdb35d56c05b3e6fc1522ad53828ca33/test/test.go#L120-L212

ParseTestResults は長いのでこちらに載せないが、要点をまとめると、

  1. testRootDir ($BITRISE_TEST_DEPLOY_DIR) 配下の各ディレクトリ (以後 testDir) に対して走査を行う
  2. testDir から step-info.json を取得する、当該ファイルがない、もしくは指定された scheme に合致しない場合は対象ディレクトリに対する処理をスキップ
  3. testDir 配下の各ディレクトリに対してファイル取得を行う
  4. 取得した各ファイルに対して、対応フォーマットだった場合には内容を読み取って返却する resultsResult 型のデータ構造として追加する、その際 testDir 配下の各ディレクトリに test-info.json が存在することを期待している

という感じになる。ここから、単にテスト結果のディレクトリを $BITRISE_TEST_DEPLOY_DIR に配置しただけでは、step-info.json がないのでアップロード対象にならないので Test Reports で表示できないということがわかる。また、仮に step-info.json が存在したとしても、さらに各 test phase (Android というか gradle でいうところの各 task, testDebugUnitTest とか testReleaseUnitTest とか) に対して test-info.json が無いといけない。

test-info.json については関数内で test-name という string 型の property があれば良いことがわかるが、 step-info.json の必要な scheme については model.TestResultStepInfo を見る必要がある。これは別の repository にあって、該当するのは以下のリンク先にある。

https://github.com/bitrise-io/bitrise/blob/master/models/models.go#L128-L134

とりあえず必要な scheme は↓のとおり

{
  id: string,
  version: string,
  title: string,
  number: number
}

ということでアップロード側が対象を認識する部分についてはなんとなくわかったので、今度は対象を作って配置する側で、主にテスト結果ファイルや step-info.jsontest-info.json の中身がどうなっていればよいのか? を見るために Android Unit Test の repository をのぞいてみる。

とりあえず main.go から、関係するのはこの辺: https://github.com/bitrise-steplib/bitrise-step-android-unit-test/blob/dd2535d711f8515202beb3f02ef43c9b2c268b5b/main.go#L215-L233

artifact によって unique なディレクトリを作って、そこに xml を export してるっぽいことが読み取れる。ディレクトリは <module>-<variant> って名前。Export 処理については testaddon/testaddon.go の方で、test-info.json 作って xml$BITRISE_TEST_RESULT_DIR/<module>-<variant>/ の下にコピーしてるだけ。 $BITRISE_TEST_DEPLOY_DIRサブディレクトリを指す環境変数だそうな。

さて step-info.json についてまるで触れられてないけどどういうことなんでしょう。この辺でもういいやってなって諦めた。

追記 (2019-06-16)

追記終わり

さいごに

多分 test の後に script step で JSON をいい感じに作ってテスト結果と一緒に配置すれば指定の test step を使わなくても Test Reports が使えるのだろうけど、調査だけで怠くなったのと完全にレールを外れたことしてるなって感じて、それを解決方法にしたくないという気持ちになったので試してない。

Android で Test Reports を使いたい人は大人しく Android Unit Test を使おう、というべきところなのだろうけど、この step も問題があって、1 step で1つのモジュールに対してしかテストを実行できないし、project root 直下のモジュールしか認識できないのでグループ分けとかでもっと下の階層にモジュールが存在する場合は Android Unit Test でそれを実行できないし、例えば JaCoCo とかで coverage report を作成している場合はそれ用の task を実行してると思うけど Android Unit Test は モジュールと build variant しか指定できなくて test<Variant>UnitTest とか基本の test task しか実行できないので coverage report が欲しかったら別途 step を実行しなきゃできないとか、とにかく融通がきかない。

Android project で任意の gradle task を使ってテストを実行したい場合には Gradle Unit Test という step があるけど、当然こっちには Test Reports 向けの export 処理は入ってなくて、やっぱり欲しいって人はいて feature request が既に投稿されている。

discuss.bitrise.io

また、Flutter project 向けにも Test Reports に対応する request も今日投稿されていた。

discuss.bitrise.io

このような感じで、現状 Test Reports を活用するには Bitrise 側の準備というか状況が全然足りてなくて、みんながみんな自分の use case に応じた feature request を送ったり、これからも送られるだろうなという感じなのだけど、その要望に対してそれぞれの test step に Test Reports 向けの処理を埋め込むという解決法をとると、これまで作ったものにもそうだし、これから新たに test step が追加される場合にも逐一その処理を追加することになって手間だよなーと感じたし、現行の実装を見るにテスト結果を格納しているディレクトリの場所について限定された想定しかされてなくて融通効かなさそうなの嫌だなーって思ったので、独立した step にして project の種類や構成、使用してる step に依存しないようにしてほしいなーってことで私も feature request を投稿した。

discuss.bitrise.io

個人的には repository 中を適当に走査して、対応する format のファイルを全部 $BITRISE_TEST_RESULT_DIR に放り込んで、あとは必要な json を適当に生成してよしなに体裁を整えてくれれば良くて、例えば複数モジュールに対するテスト結果があったとしても、全部1つのグループにまとめられてしまっても構わないと考えてる。まあファイルの存在するディレクトリの情報を取っておいて、それを元に metadata とか格納先ディレクトリを区別するとかでできるのかもしれないけど。

この機能周辺に関しては悪い意味での easy に寄ったスタートしてるなーって感想で、触っててストレスしか感じないような現状なので早く使いやすくなってほしい...

Bitrise: Repository で bitrise.yml を管理している場合の Bitrise Start Build による workflow の並列実行を行う

Bitrise は基本的に1つのトリガーに対して1つの workflow しか実行させられないが、 Bitrise Start Build という step を用いることで、複数の workflow を並列に実行できるようになっている。以下では主に GitHub などの repository で bitrise.yml を管理・運用しながら Bitrise を利用している場合の Bitrise Start Build の導入方法や、実際に私が導入した際の雑感などを書いていく。

事前準備

Bitrise Start Build を実行するには access token が必要で、これは各個人のアカウントで生成する personal access token のことである。なので、適当なアカウントで Account setting -> Security から token を生成し、Workflow Editor の Secrets 適当な名前で登録しておく。

(寄り道) GUI でのセットアップ

今回の主題は repository で管理している bitrise.yml で運用している場合の導入方法についてだが、yaml を書く際のドキュメントは存在しない*1ので、その場合でも先にGUI側でお試し workflow を作ってどのような設定があるか見てみるのが良い。Bitrise Start Build についてもGUI側での設定方法ならば上記の access token についても含めて公式のドキュメントにおおむね書かれている。大雑把に要点を挙げると

  • Bitrise Start Build step を追加
  • 並列実行したい workflow を羅列
  • 用意した access token を登録

という感じ。

また、ドキュメントには記述がないが、実行元の workflow で定義した環境変数を引き継ぐ為の設定 Environments to share というものがあり、これによって1つの workflow に対して実行元 (設定した環境変数の値) に応じて振る舞いを変更する、といったことにも対応可能になっている。

ついでに、 Bitrise Start Build の step の後に他の step を追加して、並列実行した workflow の実行後にそれを動かすようにしたい場合以下の2種類の方法がある。

  • Bitrise Start Build の設定にある Wait for buildstrue にする
  • Bitrise Wait for Build という step を Bitrise Start Build の後に追加する

これらの振る舞いは完全に一緒っぽいのでそのうちどちらかがなくなるのではないか。

Repository でbitrise.yml を管理している場合のセットアップ

bitrise.yml での記述

yaml における Bitrise Start Build の step 名は build-router-start であり、設定など含めると以下のようになる:

  steps:
  # ssh activation, cloning repository, etc...
  - build-router-start:
      inputs:
      - access_token: "$ACCESS_TOKEN"  # 事前準備で用意した access token
      - workflows: |- # 実行する workflow のリスト
          foo
          bar
          baz
      - wait_for_build: false # optional: default false
      - environment_key_list: "$KEY1\n$KEY2" # optional

これでめでたく workflow の並列化が完了... ではない。単に上記の step を追加しただけで実行すると以下のようなエラーで終了してしまう:

Failed to start build, error: failed to get response, statuscode: 400, body: {"status":"error","message":"workflow (foo) did not match any workflows defined in app config","slug":"[REDACTED]","service":"bitrise"}

これはなぜかというと、現在の Bitrise Start Build で実行可能な workflow はGUI側で定義されているもののみだからである。
ここで諦めて大人しくGUI側に workflow の定義を移すこともできるが、折角変更の管理ができるように repository 側で持たせているのだから、その状態を維持したままで並列実行を動かせるようにしたい。とはいえ repository 側の bitrise.yml だけではどうにもできないので、GUI側への最小限の変更で動かせるようにする方法を紹介する。

GUI 側での設定

今の所参考になる解決策は以下の discussion で挙げられている手法かと思われる。

discuss.bitrise.io

要点は以下の3つ:

  • GUI側で、Bitrise Start Build で実行する対象と同名の workflow を定義する
  • 環境変数を用いて、実行するべき workflow を保存しておく
  • bitrise run環境変数で保存していた名前の workflow を実行する

ちなみに上のリンク先の定義は改善の余地があって、自前で WORKFLOW_TO_RUN のような環境変数を用意しなくても、$BITRISE_TRIGGERED_WORKFLOW_ID というデフォルト環境変数があり、同名の workflow を定義しているならこれが使えるので、こちらを使うことで定義をスッキリさせることができる。

  run_from_repo:
    steps:
    - activate-ssh-key: {}
    - git-clone: {}
    - bitrise-run:
        title: continue from repo
        inputs:
        - workflow_id: "$BITRISE_TRIGGERED_WORKFLOW_ID"
  foo:
    after_run:
    - run_from_repo
  bar:
    after_run:
    - run_from_repo
  baz:
    after_run:
    - run_from_repo

この方法を用いる場合の注意点として、bitrise-run で実行した workflow 内の script step で set -e をつけておかないとタスクが失敗したにも関わらずその後の処理も続いて workflow が成功扱いになってしまうみたいなことがあったので共有しておく。

雑感

  • 現時点では Bitrise Start Build はGUI側のみでの workflow 構築しか想定されておらず、repository で bitrise.yml を管理している場合には定義が repository 側とGUI側に散ってしまい嬉しくない。Bitrise 的にはGUI側で全てを完結してほしそうにしているが、 workflow の変更管理がそれだけではできないのでGUIで完結させたいなら早く運用でカバーする以外の管理方法と提供してくれという気持ち。
  • wait: true にしている場合、実行したコンテナの結果を待っている間そのコンテナは占有されたままとなるので、CircleCI と比べるとコンテナが枯渇しやすい。
  • Bitrise では現在 branch 単位でしかキャッシュを持てず、他にコンテナやCIパイプライン間でファイルを共有するすべがないので、たとえ wait: true にしたとしてもそれぞれの workflow の成果物を収集してまとめて何かをするというのはできなさそう。
    • 基本的には build_router_start を実行する workflow はそれのみを step として持ち、自己完結した workflow を並列実行して自身は wait しない、という構成にするのが一番無駄が無い気がする。
    • Danger に色々な仕事をさせていて、成果物の収集は互いに独立しているので並列化したかったのだけど残念...

まあ CircleCI の workflow とかと比べても洗練されてないというか色々足りてないなーという印象だけど、まだリリースされてそれほど時間が経っていないことだし、今後に期待という感じだろうか。

References

*1:Bitrise は基本的にGUI側での設定の仕方しかドキュメントにまとめてくれない

Android で unidirectional data flow で設計することについてのメモ

Android と Flux とか unidirectional data flow とよばれるものの関係についてかんがえていることのメモ書きのために自分の過去の tweet をまとめる場所

******

From: U-NEXT (2016/05~2019/02)
To: CyberAgent (2019/03~)

2/15が最終出社日でした。

U-NEXTのみなさまには大変お世話になりました。火曜に退職決まって金曜に最終出社という唐突ムーヴ失礼しました。タイミングが良かったんです。結局挨拶もそこそこみたいな感じになってしまったので話し足りなかったとかあったらご飯とかお酒とか誘ってください。

ところで昨日以下のようなツイートをしました。

これはどういうことかというと、既に内定承諾はしているのですが、入社までの期間が短いため配属がまだ調整中だけど入社手続きをもう進めちゃうねみたいな状況で、具体的な配属がまだ決まってないので決まってからブログでも書こうということでした。でも待ってたら来週末くらいとかになるかも知れないし、イベント的にそこまで引っ張る必要もないよなーって思ったのでもう書いてしまっています。

追記:
配属はマッチングエージェントでした。タップル誕生の Android アプリ開発などをやります。

www.matchingagent.co.jp

追記終わり

というわけで、サイバーエージェントのみなさまこれからよろしくお願いします。人事のみなさまにおかれましては月の半ばにもかかわらず「今月で退職できるみたいだから来月入社しますね!」という唐突ムーヴすみません。本当にタイミングが良かったんです。あと多分最初に連絡をもらった時の「明日🍣どうですか?」の件をいまだに面白がってるのだと思います。

なお、この記事は以下のレギュレーションに則って書かれました。