以下のような親digと子dig1・2を用意し、親から子をcallした場合とincludeした場合とでそれぞれでexport/storeした変数の可視範囲を調べてみた
parent.dig
_export:
parent_export_var_1: parent_export_var_1_value
parent_export_var_2: parent_export_var_2_value
parent_export_var_3: parent_export_var_3_value
rb:
require: store_var.rb
+store1:
rb>: StoreVar.store_var
name: parent_store_var_4
value: parent_store_var_4_value
+child_call:
call>: child_call.dig
+env1:
sh>: env | grep _var_ | grep -v _command= | sort
+store2:
rb>: StoreVar.store_var
name: parent_store_var_5
value: parent_store_var_5_value
!include : child_include.dig
+env2:
sh>: env | grep _var_ | grep -v _command= | sort
+store3:
rb>: StoreVar.store_var
name: parent_store_var_6
value: parent_store_var_6_value
child_call.dig
_export:
parent_export_var_1: parent_export_var_1_value_override_by_child_call_export
child_call_export_var_1: child_call_export_var_1_value
rb:
require: store_var.rb
+store1:
rb>: StoreVar.store_var
name: child_call_store_var_2
value: child_call_store_var_2_value
+env1:
sh>: env | grep _var_ | grep -v _command= | sort
child_include.dig
_export:
parent_export_var_2: parent_export_var_2_value_override_by_child_include_export
child_include_export_var_1: child_include_export_var_1_value
rb:
require: store_var.rb
+store:
rb>: StoreVar.store_var
name: child_include_store_var_2
value: child_include_store_var_2_value
+env:
sh>: env | grep _var_ | grep -v _command= | sort
store_var.rb
class StoreVar
def store_var(name, value)
Digdag.env.store({name.intern => value})
puts "stored #{name}:#{value}"
end
end
$ digdag run parent.dig
2017-02-03 16:16:02 +0900: Digdag v0.9.3
～略～
2017-02-03 16:16:09 +0900 [INFO] (0016@+parent+store1): rb>: StoreVar.store_var
stored parent_store_var_4:parent_store_var_4_value
2017-02-03 16:16:11 +0900 [INFO] (0016@+parent+child_call): call>: child_call.dig
2017-02-03 16:16:12 +0900 [INFO] (0016@+parent+child_call^sub+store1): rb>: StoreVar.store_var
stored child_call_store_var_2:child_call_store_var_2_value
2017-02-03 16:16:13 +0900 [INFO] (0016@+parent+child_call^sub+env1): sh>: env | grep _var_ | grep -v _command= | sort
child_call_export_var_1=child_call_export_var_1_value
child_call_store_var_2=child_call_store_var_2_value
child_include_export_var_1=child_include_export_var_1_value
parent_export_var_1=parent_export_var_1_value_override_by_child_call_export
parent_export_var_2=parent_export_var_2_value_override_by_child_include_export
parent_export_var_3=parent_export_var_3_value
parent_store_var_4=parent_store_var_4_value
2017-02-03 16:16:14 +0900 [INFO] (0016@+parent+env1): sh>: env | grep _var_ | grep -v _command= | sort
child_call_store_var_2=child_call_store_var_2_value
child_include_export_var_1=child_include_export_var_1_value
parent_export_var_1=parent_export_var_1_value
parent_export_var_2=parent_export_var_2_value_override_by_child_include_export
parent_export_var_3=parent_export_var_3_value
parent_store_var_4=parent_store_var_4_value
2017-02-03 16:16:15 +0900 [INFO] (0016@+parent+store2): rb>: StoreVar.store_var
stored parent_store_var_5:parent_store_var_5_value
2017-02-03 16:16:16 +0900 [INFO] (0016@+parent+store): rb>: StoreVar.store_var
stored child_include_store_var_2:child_include_store_var_2_value
2017-02-03 16:16:17 +0900 [INFO] (0016@+parent+env): sh>: env | grep _var_ | grep -v _command= | sort
child_call_store_var_2=child_call_store_var_2_value
child_include_export_var_1=child_include_export_var_1_value
child_include_store_var_2=child_include_store_var_2_value
parent_export_var_1=parent_export_var_1_value
parent_export_var_2=parent_export_var_2_value_override_by_child_include_export
parent_export_var_3=parent_export_var_3_value
parent_store_var_4=parent_store_var_4_value
parent_store_var_5=parent_store_var_5_value
2017-02-03 16:16:17 +0900 [INFO] (0016@+parent+env2): sh>: env | grep _var_ | grep -v _command= | sort
child_call_store_var_2=child_call_store_var_2_value
child_include_export_var_1=child_include_export_var_1_value
child_include_store_var_2=child_include_store_var_2_value
parent_export_var_1=parent_export_var_1_value
parent_export_var_2=parent_export_var_2_value_override_by_child_include_export
parent_export_var_3=parent_export_var_3_value
parent_store_var_4=parent_store_var_4_value
parent_store_var_5=parent_store_var_5_value
2017-02-03 16:16:18 +0900 [INFO] (0016@+parent+store3): rb>: StoreVar.store_var
stored parent_store_var_6:parent_store_var_6_value
わかったこと：
- 子をcallで実行した場合のタスク名は
+parent+child_call^sub+env1、子をincludeで実行した場合のタスク名は+parent+env。call時には「+<子dig名>^sub」が挟まるがinclude時には挟まらない。includeは「親自身が実行した」ことになっている感じ。 - 親のexportでの「変数の定義」はcallした子にもincludeした子にも伝わる。
- callした子のexportでの「親変数の上書き」「変数の定義」は親には伝わらない。
- includeした子のexportでの「親変数の上書き」「変数の定義」は親に伝わる。というかincludeは「親自身が実行した」ことになっている。だから親のexportで定義した変数と一緒に他の子にも伝わっている。
- Rubyでstoreした変数は親/callした子/includeした子のどこでstoreしてもその後の全体に伝わる。
- 親digにおいてincludeはcallよりも後に書いてあるのに、callした子の実行時点で既にincludeした子のexportでの「親変数の上書き」「変数の定義」は実行済。