Right now we have to options to call another bundle from inside a (control) bundle, either using an "Install Bundle" action or launching "zac bin xyz". The latter has the advantage that the control bundle can start almost instantanously because the bundle content from the called bundle only gets downloaded upon the zac bin command. The downsides to that are a) you can easily have a typo in the bundle name you#re calling, b) if you rename those bundles the zac bin command brakes, c) if you use the GUID instead of the bundle name in the zac bin command then the step loses it's readability and d) the called bundle needs to be assigned to the device beforehand. On the other hand, if we use the "Install Bundle" action the control bundle gets bigger and bigger with each added sub-bundle leading to a delayed start of the first bundle action.
So the solution might be to add an option to the "Install Bundle" action to explicitly include or exclude the bundle content so we a) have a very flexible way to link to another bundle and b) to delay the bundle content download to the step where it actually gets called instead of "pre-loading" all of the content.
by: David B. | over a year ago | Application Mgmt
Comments
We are working around this by hardly using the content repo at all.
We found the content repo to suck badly due to the low overall performance and we do not have use cases for distribute-by-schedule/install-by-request schemes, so all we're putting in the content repository are small-ish script and configuration files. Installation binaries are exclusively hosted on file shares.
This feature already exists.
You can disable the "Distribute Files" action on the Distribute tab.
This will prevent the "Pre-Distribution" of content in advance.
The content will only be distributed when the action is actually ready to run.
This can prevent content from being downloaded needlessly if certain install actions may not be needed for certain devices.