-
Notifications
You must be signed in to change notification settings - Fork 394
Allow specification of multiple Features bundles #627
Allow specification of multiple Features bundles #627
Conversation
#625 will most likely allow tests on this to pass. Will rebase once that is merged. |
Restarting tests. Rebase should not be necessary. |
<drush command="fra" assume="yes" alias="${drush.alias}"> | ||
<option name="bundle">${cm.features.bundle}</option> | ||
</drush> | ||
<foreach list="${cm.features.bundle}" param="bundle" target="setup:update:features-import" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@timcosgrove I believe that this changes requires cm.features.bundle to be an array (it can never be a string).
If that is the case, we should change the variable name to cm.features.bundles and change the example here to be an array.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@grasmash I tested it with yml formatted as such:
cm:
features:
bundle: my_feature_bundle
This worked as expected, feeding into the foreach as an array with a single value.
I think 'bundles' is clearer myself but I wanted to not breaking existing project.yml.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Testing confirmed the following forms all feed validly to the ForEachTask:
single:
cm:
features:
bundle: my_feature_bundle
comma-delimited:
cm:
features:
bundle: my_feature_bundle, my_other_feature_bundle, my_last_feature_bundle
per-line:
cm:
features:
bundle:
- my_feature_bundle
- my_other_feature_bundle
- my_last_feature_bundle
My personal preferences is for the last option, but it looks like Phing is happy to take either form.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And to be clear I think 'bundles' is clearer semantically but again I wanted to make sure this didn't break anyone's build.
K, I'm going to merge as is for the moment but I will likely change to bundles. I am concerned about backwards compatibility--we need a way to roll out delta updates that take care of changes like this. |
A simple way to handle the property name change would be to make 'bundles' the default, and have a simple check somewhere that sets |
#626
We would like to be able to specify multiple Features bundles.
I would have liked to change the property name to cm.features.bundles but left it as-is for backwards compatibility sake. I've confirmed that the ForEachTask is perfectly happy with a single item.