A bit of background... We are building a strategic print workflow system using RPD in Hub & Spoke config. We are supporting this by embracing a DevOps culture & an automated CICD release model using pipelines in Azure DevOps.
For code version control, we export RPD system objects (workflows, selectors, printers etc) via the REST API as individual XML files and store them in a code repository. We also have a similar repository driven process to control Feature roll outs using a cmd line execution of the installPDUpdate.pl script.
By using this process we can very accurately control each systems content and maintain a high level of visibility over any system change. We want the systems to contain only the objects which are being used, we do not want to unnecessarily manage objects we don't use in processing.
When installing Features, some come packaged with "sample" objects as part of the install.. Example - AFPSupport Feature comes with multiple sample workflows. These sample objects are "nice to have" when first starting out on the product - they give you a push in the right direction - but once you are writing/creating real life examples, they become a bit useless & overall less desirable to keep on the system.
What we did
We installed base feature AFP Support and then updated the system to contain only our version controlled objects - effectively removing any sample objects at the same time. When we tried to install the DocPool Feature, it failed due to a link between a sample object workflow which was part of the DocPool package and another sample object which was part of the AFP Support package. The failed install left other areas of the system corrupt. For example REST API exportAll call did not work & only returned exit code 500.
Issue found
Some installable Features contain sample objects which have references to other sample objects that came packaged as part of other Features.
This object to object link creates a mass web of dependencies at a lower level than just "Feature functionality". We understand the dependency link of one Feature's functionality & another Feature, that makes sense. The object dependency, not so much.
If you could review the current process of forcing sample object installs when installing Features that would be good... One idea we bounced around here was to offer some kind of option to ignore sample objects as part of a Feature install. Effectively, we only want the Feature functionality not any sample objects which come packaged with it.
