# 21st Workflow Meetup まとめ(10/30)

2019-10-30(Wed)
10:00 - 19:00 まで。
いまのところ、東京単独開催予定
理研日本橋東京連絡事務所、会議室１

# 全体

次回

## ワークフローのテストなどについて

- 聞きたいこと、議論したいことはこの下におねがいします。
- テストデータはどこにおいていますか？
- テストデータのサイズはどれくらいにしていますか？
- どこで、テストしていますか？
- マシンのスペックは？
- どうやってテストしていますか？
- 何をテストしていますか？
- どこまでテストしていますか？
- 頻度
- コンテナつかっていますか？
- テスト自動化したら楽になりますか？

## Test data の置き場所

### 何を基準に選ぶか

- オープンかクローズドか
- テストの目的
- dev
- ユニットテスト
- フォーマットチェック
- ツールの性能のテスト
- 得られるべき出力が得られるか
- ツール間結合テスト
- WF のテスト
- ops
- 実行環境のテスト (デプロイのテスト)
- 可搬性チェック
- ファイルサイズ
- DOI 振りたいかどうか

### 選択肢

- 公開されてるやつを使う
- 野良 fastq
- ちょっとやりたいときは便利
- CI には向かない（なくなる危険がある）
- 公共レポジトリ e.g. SRA に置いてあるやつとか
- NCBI FTP
- ftp.ncbi.nlm.nih.gov/

          -r--r--r--   1 ftp      anonymous 10738466816 Feb 16  2018 10GB
          -r--r--r--   1 ftp      anonymous 1074790400 Feb 16  2018 1GB
          -r--r--r--   1 ftp      anonymous 53688139776 Feb 16  2018 50GB
          -r--r--r--   1 ftp      anonymous 5369757696 Feb 16  2018 5GB

- GitHub
- up to 100MB
- Git LFS を使えば、もっといけるけど、クライアントにも LFS をいれてもらう必要がある。
- ダウンロード
- 数 MB 程度ならおける
- unittest のようなものには、使えるが、このサイズでは、生物学的に意味があるようなデータを置くのは辛いかもしれない。
- zenodo
- zenodo.org
- up to 50GB
- GitHub repo との連携があって GitHub repo のスナップショットの保存と DOI のアサインをしてくれる
- e.g. https://github.com/inutano/cwl-metrics-manuscript
- Figshare
- https://figshare.com
- files up to 5GB
- 交渉すれば 5TB/file までいけるらしい？
- https://knowledge.figshare.com/articles/item/uploading-large-datasets-using-the-desktop-uploader-or-api
- テストデータは、public ならばどこいおいておいてもよいが、ダウンロードをするスクリプトを用意しておく（レポジトリに含める必要はない）
- ダウンロード用のリンク切れが起こるので、印象がよくない（メンテナンスを忘れがち）
- ダウンロードの成功率が高くない場合がある
- データの更新をしたが、スクリプトの更新わすれがある
- S3 or public cloud storage
- クローズドでも使えるよ！！！
- 楽だがお金がかかる
- AWS から取り出し
- wasabi
- https://wasabi.com
- https://wasabi.com/cloud-storage-pricing/
- Data I/O が無料
- 自前サーバー
- NBDC Database Archive
- 無料!!
- 本来の目的がデータセットの保全
- テストデータだけだと…？交渉次第かな？
- ChIP-Atlas はここに置いてる
- DOI を振ってくれるがデータセット単位なのでファイル単位ではない
- スクリプトのメンテ：データを毎日ダウンロードして、md5 をチェックする
- クローズドのデータの場合は
- 自前サーバー
- S3 の権限設定
- 1, 2 個なら楽だけど、数が増えると大変になる。
- nf-core の場合は、テストデータ用のレポジトリを用意させる
- https://nf-co.re/developers/adding_pipelines#setting-up-a-test-workflow
- Dropbox, Google Drive だと
- curl のヘッダが大変なことになる。
- 25MB あたりをこえるとなにかが面倒になる。
- https://qiita.com/nxzz/items/f2a595389f39206235e8
- 10MB までは、GitHub、それ以外は、
- zenodo
- figshare
- NBDC Database Archive
- 置くのが適切であれば、ここがよい
- 自前サーバ
- セキュリティ的な問題を考えておく必要がある

## Test data のサイズ

- single-end 1M read 150bp を gzip 圧縮で 80MB
- ぎりぎり github におけるが、おすすめはできない。
- （クローンも時間かかる）
- ツールが正常に稼働する最低のファイルサイズの見極めが難しい問題
- e.g. MACS2 とかはファイルサイズ小さすぎる（リード数削りすぎる）とピークが検出されないのでヘッダだけの出力が出る
- 結合テストでコケる
- ツールが正常終了しない場合もある (deeptools)
- 逆に割当メモリに対してファイルがでかすぎて正常終了せずプロセスが完了しない問題
- CI とかで小さいマシンで回すときに神経を使う
- 一旦フルサイズで WF を最後まで回して、最後の結果から逆算してサブセットを出す
- e.g. full reads で map して chr ごとのリードをカットして fq に戻して使う
- １つだけがんばる
- 理想的ではあるが、全部やるのは大変
- dev(研究者)と適切なサイズのテストデータについて議論できるとよい
- 素早くまわせて小さなサイズというのがみつかるとよい
- ただし、モチベーションがあがらないケースもあるかもしれない

### 圧縮の選択肢

- 圧縮しすぎると使いにくいからやめろ
- bzip2, xz だと展開に時間がかかる
- テスト環境によってはつらい
- gzip だと、ツールが圧縮ファイルにも対応している
- CPU に負荷をかけるかネットワークに負荷をかけるか
- **みんながみんなネットワークが太いわけではない**

## Test の実行場所

- dev
- 開発環境と想定される実行環境
- 特定の計算機環境
- GPU ごりごり系とか閉鎖環境とか
- ops - 実際にデプロイする環境 - 比較対象の環境 - 自前の環境で動かないときに他所では動くのかチェック - クラウドとか - CI ではなくて、きれいなマシンを都度つくってテストする - テスト用 AMI を作っておくと便利
- 最低限のテスト用ツールとかコンテナエンジンとかを入れとく
- CI 環境
- ただし、時間と使用できるメモリなどの制限によりできないこともある

## Test のやり方

**_金言: テストは忘れたころに落ちる_**

### 理想

- 1 コマンド
- 引数なし
- ステータスコードで成功失敗がわかる
- ログが出る
- 環境が悪いんだったら教えてくれる
- 実行前にチェックしてくれると最高
- 気の利いたテストスクリプトの思い出
- なぜ落ちたかわかりやすいエラーメッセージをだしてくれる
- 調べさせたら負け
- 直し方まで書いてあるとよい
- 数が多くてもストレスがたまらないので良い
- ストレスがたまるのは
- わけがわからないメッセージになっている（エラーとだけ、でるとか）
- 原因と修正方法を調べないといけない
- 与えられたテストケースの実行にメモリが足りているかを調べてくれる
- メモリ
- Mac の Docker Desktop のメモリ割り当てが少なすぎる問題
- テストに使う入力ファイルが決まっているならテストに使うメモリ使用量は事前にわかるはず！
- データをダウンロードするとき
- もとのファイルが残っていないことを確認してくれる
- 正しいデータがおちてきていることを確認してくれる

### 現実

- cwltest
- https://github.com/common-workflow-language/cwltest
- CWL 専用
- 出力が JUnit 形式で人間にはつらい
- tonkaz
- https://github.com/suecharo/tonkaz
- コマンドラインでの実行からテストケースを作成してくれるやつ
- nextflow の nf-core では Travis CI を GitHub で動かすことが developer に強制されている
- https://nf-co.re/developers/adding_pipelines#setting-up-a-test-workflow
- `.travis.yml`の例: https://github.com/nf-core/hic/blob/master/.travis.yml
- `nextflow run ${TRAVIS_BUILD_DIR} -profile test,docker` ：`test,docker` で指定された config 内セクションが内部で読み込まれるようにすることで、テスト用に長いオプション等を CUI でいちいち書くことが防げる

## 何を Test するのか

- dev
- ops
- わかりやすいケース
- いつも出力が一定であるならば、チェックサム
- GUI ツールをテストするのか
- **したくない**
- が、できないわけではない（できるとはいってない）
- フレームワークを使ってもなおめんどくさい
- そもそも GUI は自動化しにくい
- GUI の操作に再現性がないことが多い
- 対象は GUI なのにテストは CUI でやってるのでいったりきたりするのがだるい
- 週に一度ポチポチしてくれる人を雇う方がトータルコスト安いのでは
- メカニカルタークだ！！
- テストフレームワークが存在はしている
- [selenium](https://docs.seleniumhq.org)
- [Geb](https://gebish.org/)
- [Headless Chromium](https://chromium.googlesource.com/chromium/src/+/lkgr/headless/README.md)
- [RaiMan's SikuliX](http://sikulix.com/)
- GUI 一般
- html 解析
- バージョンが想定しているものかをチェックする
- どこまで厳密にやるのか
- 自分が想定するケースだけやればよいのか？
- それともパラメータ全組み合わせでテストする？
- 全部は現実的ではない
- 落ちるケースもテストするのか？
- 入力がだめ
- ファイルが空だとか
- 必須の引数が足りない
- テストしないと「動いているように見えるけど結果がおかしい」という調査に非常に時間がかかる状態になる
- 全部のオプションを試すか？
- ツールが複数あるときは、それぞれきちんと実行されている
- シードが固定できず、出力が一定でないのでチェックサムでチェックができないケース
- 0 バイトでないことのチェック
- おおよそ 100MB くらいのファイルがでてくることが想定されるなら、ある程度の範囲にファイルサイズがおさまっているかのチェックをする
- ファイルが存在するというチェックだけだとすりぬけてしまうケースがある
- 自動で日付を含むログファイルを出力するケース
- 実行するたびファイル名が変わる！

## 頻度

- テストは異常に気付くためにある
- 短ければ短いほど、どこで・いつ壊れたかが把握しやすい
- どこで・いつ壊れたかがわかると直しやすい
- テストは、自分の力が及ばないところに問題があることも気づくことができる
- 相手のサイトが生きていることのチェック
- dev
- 開発中(セーブするたび)
- ⌘+S でテストが走るべき
- むしろ自動セーブと組み合わせて、しばらく入力がなかったらテストが走るべき
- テストが遅すぎてつらくなることもあるのでテストの設計には注意すべし
- commit する度
- push する前
- PR マージする前
- ops
- 管理している環境の都合が許す限り高い頻度で
- 依存ライブラリのバージョン変更で既存コードが壊れるかも
- 毎日
- 毎秒
- いつコケたのかがわかるのが一番大事
- インターバルは可能な限り短いのがよい
- テストの実行時間とマシンへの負荷と相談するのがよい
- 「あなたが XX 時 XX 分に XX するまではちゃんと動いてました」

## Container を使うか？

- 使う
- 使う
- テストならコンテナを使わない手はない
- 大型計算機センタによっては、使えない環境もある
- Singularity
- Docker の将来
- ネイティブ環境のテスト
- 環境変数のテスト
- 実行者の環境変数に依存しないことを確認したいので、コンテナを使うとよいケースは多いだろう
- 特殊なハードウェアを使うとか
- 閉鎖環境とか
- パッケージマネージャを使うときは、いろいろなことに十分注意する
- バージョンと依存関係
- 他のパッケージとの衝突
- パッケージマネージャそのもののバージョン
- パッケージマネージャで管理されているパッケージのバージョン
- パッケージマネージャで管理されているパッケージの管理者

## CI について

- エディタにシンタックスハイライトがあるときはいれておくべき
- いじるのは造ったとき程度なので、文法をおぼえておけない
- タイプミスをすぐにみつけることができる
- 毎日回すということは技術的には可能
- 大抵の CI サービスでは定期的な CI 実行をサポートしている
- 性能や制限時間・テストできる環境に注意
- 制限時間
- タイムアウト
- 月ごとに CI に使える時間が決まっている場合がある
- 環境
- Windows 環境・mac 環境のテストに対応していないかも
- メモリ
- バイオインフォ向けには、小さすぎるケースがある
- CPU
- バイオインフォ向けには、十分な数のコアがないかもしれない
- 対策
- 金の弾丸 (財力で殴る)
- Travis CI
- 日毎、週毎、月毎の中から設定できる（特定の時間に走らせることはできない）
- Circle CI
- デフォルト１０分無応答時間があると、落ちるので長くかかるツールの場合はこの設定変更が必要
- ローカルでテストするためのツールが存在
- GitHub Action
- よくわからない理由で実行できないことがあった
- 11/13 から、GA になる。
- Linux, macOS, Windows に対応
- Bitbucket Pipelines
- 無料版だと 50 分/月しか使えない
- Gitlab CI (クラウド)
- Github のリポジトリもテストできる
- 素直な代わりに泥臭いところも書く必要があるかも
- 自前マシン
- サーバー管理の手間が増える
- メモリとか、CPU とかはサーバーを用意できるのでいかようにでもできるというメリットがある
- Jenkins
- 管理が大変になる
- Jenkins おじさんも含めたシステム構築
- Jenkins おじさんの群れ
- GitLab CI (オンプレ)
- クラウド <-> オンプレ の移行が容易
- アップデートが頻繁で追いかけるのは大変
- 月 1 定例 + セキュリティアップデート
- Slack への通知があると便利
- メールにはりつかなくてよい
- メールサーバを管理しなくていいのが最高
- ワークフロー開発者
- 人に渡したいならば実行するだけの人のケースもかんがえておくひつようがある
- 自分も渡した人も同じスクリプトを実行して正常に終了することを確認できる
- 自分の使うツールの使用するメモリサイズや、実行にかかる時間は把握しておき、可能なら、公開レポジトリのREADMEに書いておくとよい
- 「README をよんでね」、で、済む問い合わせがある
- 全部が全部一箇所でじっこうする必要はないので、
- ワークフロー全体は手元の強力なマシン
- 遺伝研、別な強力な環境でのテストなどもやりしゃすい
- 個別のツールで、小さなサイズでも動くものは、Travisなどを活用するという手もある
- SRAからFastqにする部分は、小さなサイズのものを指定して変換がただしく行えることを確認できる
- こうしておくと、APIの変更などにも対応できることがある

## アドベントカレンダーやりたいです

12/3-6 分生、福岡
12/9は、Galaxy Meetup 日本橋
12/12は、Galaxy Meetup 福岡、九州バイオインフォコミュニティと共催
12/16を、Workflow Meetupを予定

- CWL
- 1日1CWL toolを目標に、CWL絡みをなにか書く
- [`zatsu-cwl-generator`](https://github.com/tom-tan/zatsu-cwl-generator) と [`cwl-for-remote-container-template`](https://github.com/tom-tan/cwl-for-remote-container-template) の紹介をしたい
- Galaxy
- 1日1Galaxy toolを目標に、Galaxy 絡みの何かを書く
- Workflow
- positive から、negativeまで、なにか記事をかいてもらえるとうれしいです。
- nextflow とか、nextflow とか、nextflow
- テストについてでもよいです

# 個別

## 石井

- VS Code の Remote Development と Live Share も紹介した
- ぼうのうさんより、conda における cwltool のインストール方法について知見を教わる
- `bioconda` と `conda-forge` で、 `cwltool` のバージョンが異なるときがある
- `conda-forge` の方が新しい
- `conda install -c conda-forge cwltool`
- おおたさんと、マイケルが現在 `bioconda` における作業をしている
- たぶん、 `conda-forge`
- `conda` 以外は
- 1. apt
- 2. pip
- 3. wheel を落としてきていれる
- [たくさんのステップを手動で実行しているものを自動化するため方法の１つ \- Qiita](https://qiita.com/manabuishiirb/items/edb8f11806204918bc5d)
- いろいろあるかと思いますが、まずは書きました。

## 坊農
- `cwltool`をconda-forgeからインストールし直し
- 大石さんと共にCWL実行テスト
- [metagenome 16s解析 by iNut](https://raw.githubusercontent.com/pitagora-network/DAT2-cwl/develop/workflow/meta16s-seq/meta16s-seq.demo.cwl)
- !!! ちゃんと動いた !!!

## 大石
- 自分が**Jenkinsおじさん**だったことを認識しました
- Travis CIを試したい
- metagenome 16s解析
- 2GB だと動かなかった
- 8GB だと動く

## 谷沢
- dfast update
- bioconda のパッケージをupdateする (todo)
- catalina 対応 (binary updated)
- 参照DBを実行時に取得するように変更

## 尾崎
- nextflow のレポジトリ [nf-core](https://nf-co.re/) におけるテストの取り組みについて紹介した
- nf-coreではワークフロー登録者（開発者）に対し、[テストのために以下を要求している](https://nf-co.re/developers/guidelines)
- コードを GitHub に置く
- Travis CI 連携をしておく
- テストデータを別レポジトリに置く
- ソフトウェアは Docker にしておく
- `.nf` ファイルは単一にする
- 芳村さんと開発しているscRNA-seq QC Nextflowパイプライン [RamDAQ](https://github.com/rikenbit/RamDAQ) のテストが辛いということで、石井さんにcronを用いた実行テストの自動化を教えていただいた
- （少しずつテストの範囲を増やしていきたい）
- 芳村さん「テストケースが多い、ワークフローのファイルを分けたことで手作業が増えた（開発の都合）」　→ 石井さん「一つにまとめると開発も速くなる！」

## 芳村
- 問い合わせ対応(すみません)
- 有識者の方々にワークフローのテストについて教えていただいた
- 目的と粒度をきちんと決める必要性を感じました
- できることから始める
- VScode を知った

## 丹生
- [cwl-language-server](https://github.com/common-workflow-language/cwl-language-server) 実装のブロッカーになっている [schema-salad#244](https://github.com/common-workflow-language/schema_salad/pull/244/) をようやく倒した
- schema-salad をライブラリとして使う場合、エラー周りの扱いがとても辛い、という Issue
- 情報がきれいに整形された文字列でしか来ない
- きれいに整形: 実行環境の `COLUMN` 変数を読んで wrapping を行ってくれる (== 実行環境によって出てくる文字列が微妙に異なる！)
- エラー箇所によって飛んでくる例外の型が異なる
- schema-salad での validation のエラーなのに `RuntimeError` や `ValueError` 飛ばしてくる(ことがあった)
- Michael によって一部解決
- これで cwlls の進捗が進む！と思って実装したら今回の修正と[関係ないバグ](https://github.com/common-workflow-language/schema_salad/pull/296)を踏んだ…
- VSCode の Live Share
- 実行が伴わないので、markdown の共同編集だけだと物足りない
- 中毒者っぽい(おおた)
- ソース編集してる下で、他の人が `apt install hogehoge` して開発環境を構築していくカオス空間を味わって欲しい
- (おざきさんの章のワークフローをnextflowにするのを、live share でやる、石井)

## 大田

- 閉鎖環境で動かしているデータビューワー dev by すえたけさん のデバッグをしていました
- バグの原因を突き止めて直してもらったりした
- 閉鎖環境でデバッグするの超しんどい
- なんかの修行っぽい
- WFのテストの話をしました
- 有意義でした、考えることは多い
- nf.core のワークフロー動かしたい
- 医療データ管理用DBのデータモデルの話をすえたけさんとした
- あとは原稿の校正をしたりしていた
- 最近 Rust を書いている
- 趣味、たのしい
- Atom の Rust パッケージがへぼなので悲しい気持ちになっている
- Atom を捨てる日が近づいている

## 末竹

- 大田さんとデータスキーマ的な話をした
- shell で書かれた pipeline を Python に書き直すというお仕事をしていた
- Jupyter で書くと debug がしやすいという知見
- (Jupyter Labが、つかいやすい、石井追記)
- shell -> python の移行が成功していることを示すために、っ出力 file の比較をするノウハウを貯めている
- (サイズが近い、実行時間が近いなど、石井追記)

## 藤野

- genomon-cwl のデバッグ
- Python パッケージ内で何が起きているか知るためにコンテナで動かすのをやめて手元にパッケージのリポジトリを clone し、print 文デバッグとかその他コードを入れた上でローカルのプログラムを pip install してデバッグすることに（CWL 関係ない）
- `pip install -d` でdevビルドできる
- `python3 setup.py -d` かもしれない、状況による
- `docker run -it hoge bash` などでシェル内で作業する方法もある
- バグの原因は判明しました

## 八谷
- human-reseq 大規模計算の準備（データセット）
- Simons Genome Diversity Project (SGDP) は、276 sample の WGS fastq file を publicly available にしてくれている
- ERR-ID と FTP URL をまとめたファイルを作成
- GWASデータ解析ワークフロー
- Impuration data から ProbABEL に繋げるところを作成中