概要
CWL の InitialWorkDirRequirement は、いろいろなことができる。
またそれにより、本来の用途と違ったことに、「使えそうにみえる」ことがあるので、
それらについて、今までに得られた知見をまとめておく
いろいろなことが、わかってくるので、随時書き足していく予定です。
結論
あくまで ステージング用途で使うものである。
ホスト側のディレクトリを、ワークフロー実行時にマウントするという用途のためにあるわけではない。
そもそもステージング用途である。
そもそもステージング用途である。
既存のディレクトリを指定したとしても、
実行用の環境(たいてい/tmp/以下のディレクトリ)に、
既存のディレクトリをコピーすることになる。
書き込み可能なディレクトリを作りたいときに使う。しかし書き込みをしてもホスト側に反映されない?
InitialWorkDirRequirement で指定されたディレクトリは、実行環境にコピーされる。
コピーされたディレクトリは、デフォルトでは、リードオンリーである。
おそらくここが気になっている人の多くは、このディレクトリになにか作成し、それを取り出したいと考えているのではないかとおもう。
デフォルトでリードオンリーなので、書き込みができないというエラーがでる。
仕様を読むと、 writable
が指定すると、新しいディレクトリに書き込みが可能となる。
実際にツールを実行しても、書き込みができないというエラーはでなくなる。
ただし、書き込みができても、それはあくまで、ステージングされたディレクトリ内であり、
ホスト側にそのデータが永続化されるわけではない。
特に構造化されていなくても良い状態で、ファイルや、ファイル群を、永続化したいのであれば、 outputs
で、とりだせばよいが、
構造化されたディレクトリをつくってそれを取り出したいのであれば、ディレクトリを作ってそれを outputs
で回収するということになる。
このとき、ホスト側に存在するディレクトリに追記する形でとりだしたいとう場合については、今後何かを書く予定。
できることが多い
- 新しいディレクトリを作る
- writable でも作れる
- 新しいディレクトリを作った上で、そこに、指定したファイルを置くということもできる
- ホスト側にあるファイルを置くこと(ステージング)もできる
- ファイルシステム上の既存ディレクトリを渡す(ステージング)こともできる
- 相対パスがおすすめ
- フルパスは、ただしく動くか不明、今後書く予定
使用例としては、compformance test にでている。
今後それらを紹介して行く予定
実際にあったケース
実際にあったケースを消化雨する予定
ケース1 --tmpdirみたいなのを.cwlのなかで指定できませんか?
https://github.com/ykohki/DAT2-cwl/blob/master/tool/sleuth/sleuth.cwl
でkallistoのoutput dirをinputにしているのですが、tmpdirがみんなバラバラになってしまうのでsleuth.Rから読み込めなくなってしまいます。安直にやるなら、sleuth.Rにkallistoのoutput dir
引数として全て渡してもいいのですが、sleuth.Rでkallisto_outのtmpdirを一箇所にまとめてそのpathをsleuth.Rの引数にとった方が少し汎用性が高いのかなと考えています。
解決方法
この方法でまとめることができた
- class: InitialWorkDirRequirement
listing:
- entry: $(inputs.kallisto_out)
writable: true