You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not sure if there is a discussion about the plans for how to alter imported plans. I think a set of interfaces could be:
prepare prepend all prepare steps to the imported plan, unless a flag is given to respect the order
finish append all finish steps to the imported plan, unless a flag is given to respect the order
environment add specified environment variables. Note, for this to be useful, the environment field should be reworked to allow for expansion, e.g. MY_VAR: ${INPUT_VAR:-default} (maybe postpone the variable expansion for another time since it might be handled by order of overwrite)
context alter the context before importing the plans
adjust prepend it to the imported plan raw data before processing, i.e. as if there was a main.fmf file that contained that data
Note
A major barrier is to specify where these commands are executed, i.e. w.r.t. imported plan or original plan's tree
There is an ambiguity of if the global provided variables (outside of the plan/plan.import key) should be considered when evaluating it. I think it should not because it can get confusing with adjust and it needs some more special treatments anyway.
With such an implementation, the plan import could also be normalized to accept a list of plan references. It is possible to partially work around it using multiple plans with inherited settings. But that does not cover something like creating a plan bundle that can be imported all at once.
What are your thoughts on this design and what order do you think these should be tackled?
The text was updated successfully, but these errors were encountered:
I'm not sure if there is a discussion about the plans for how to alter imported plans. I think a set of interfaces could be:
prepare
prepend all prepare steps to the imported plan, unless a flag is given to respect the orderfinish
append all finish steps to the imported plan, unless a flag is given to respect the orderenvironment
add specified environment variables.Note, for this to be useful, the environment field should be reworked to allow for expansion, e.g.(maybe postpone the variable expansion for another time since it might be handled by order of overwrite)MY_VAR: ${INPUT_VAR:-default}
context
alter the context before importing the plansadjust
prepend it to the imported plan raw data before processing, i.e. as if there was amain.fmf
file that contained that dataNote
A major barrier is to specify where these commands are executed, i.e. w.r.t. imported plan or original plan's tree
There is an ambiguity of if the global provided variables (outside of the
plan
/plan.import
key) should be considered when evaluating it. I think it should not because it can get confusing withadjust
and it needs some more special treatments anyway.With such an implementation, the plan import could also be normalized to accept a list of plan references. It is possible to partially work around it using multiple plans with inherited settings. But that does not cover something like creating a plan bundle that can be imported all at once.
What are your thoughts on this design and what order do you think these should be tackled?
The text was updated successfully, but these errors were encountered: