mosen/ccp-recipes

Proposal to "containerize" Inputs, and support array of products

Closed this issue · 8 comments

timsutton commented

Here's a more formalized description of something I've been talking with mosen for a while:

Currently there are a few input variables supported, such as PRODUCT_ID or BASE_VERSION, which are passed through to both the CreativeCloudFeed and CreativeCloudPackager processors via AutoPkg's variable string substitution %% pattern. I see this as presenting two problems:

  1. Because AutoPkg supports only substituting string types it's ambiguous how to substitute in boolean values, like all the *_ENABLED options. The only reasonable way I can see these working is for them to be treated like environment variable-like flags, where they're "unset" to mean false, and set to anything to be true. We then need to be careful in the processor code to not use the same methods we'd check a boolean, but instead check if the string is false-y. (These might be the same in some cases, but there can be subtle differences).
  2. The input variables that describe the actual application/version, like PRODUCT_ID, BASE_VERSION and VERSION, are just for one product. We don't have any way of specifying multiple packages if someone would want to include additional components. I'm thinking partly of some users who may wish to be able to automate a "collection" package of a few applications, but more commonly of the case where there may be some additional components you want to include in an application's package, like After Effects's Character Animator, Camera Raw (for a few applications), or Adobe Preview. In some cases there are older versions of these included automatically with an app package, but there's a newer version which could be included alongside it.

I think a solution that would fix both of these would be to do what we do for the pattern of using pkginfo Inputs in .munki recipes: we can define a dict containing all our desired configuration for the CCP package (the parameters and an array of package/baseversion/version dicts), and then the CreativeCloud* processors simply know to look for and make use of this data. We also this way avoid some noise in the recipe of all the string substitutions.

I personally would almost never be building packages with more than one component, but if we have this structure defined where it's at least assumed that it's an array (even if most of the time it contains only one element), we have that possibility without having to handle backwards-compabitility or just breaking peoples' overrides. One bit of added complexity is that when we do a sanity check of SAP codes and base version combinations, we need to do this for a list instead of just one - so the control flow around that is slightly more involved.

I'm happy to take a pass at this, but perhaps someone may see a potential issue here. It would be nice if Adobe had offered a single flag for doing the UI equivalent of checking the "top-level" box for an application in CCP: when this is checked, all the related "dependencies" (STIs?) are also checked and included with the package. We can do this ourselves with what we retrieve from the feed, of course, but I think that's not directly related to what I'm proposing here.

mosen commented

Drafted a plist structure for CCPInfo which ill be working on in branch feature/ccpinfo

            <key>ccpinfo</key>
            <dict>
                <!-- Boolean flags -->
                <key>matchOSLanguage</key>
                <true/>
                <key>rumEnabled</key>
                <true/>
                <key>updatesEnabled</key>
                <false/>
                <key>appsPanelEnabled</key>
                <true/>
                <key>adminPrivilegesEnabled</key>
                <true/>
                <key>IncludeUpdates</key>
                <true/>
                <key>is64Bit</key>
                <true/>

                <key>organizationName</key>
                <string>ADMIN_PLEASE_CHANGE</string>
                <key>customerType</key>
                <string>team</string>
                <key>Language</key>
                <string>en_US</string>

                <!-- Products -->
                <key>Products</key>
                <array>
                    <dict>
                        <key>sapCode</key>
                        <value>KBRG</value>
                        <key>baseVersion</key>
                        <string></string>
                        <key>version</key>
                        <value>latest</value>
                    </dict>
                </array>
            </dict>
mosen commented

Bit of a conundrum with versioning packages that contain multiple products.
Which version do you pick?
This is how you end up with 2015.3 I guess

mosen commented

Branch feature/ccpinfo supports the ccpinfo dict as posted above. It does not support multi product packages yet.

timsutton commented

Versioning is a conundrum with packages containing multiple products.

For Munki recipes, makepkginfo should be pretty good about generating a suitable version when it's being given a single "core" app. i.e. if I build a package with just the latest Photoshop and its own dependent updates, MunkiImporter should filter out the auxiliary updates and identify the version of the main app.

To that effect we could probably ditch this key from MunkiPkginfoMerger:
https://github.com/mosen/ccp-recipes/blob/master/Adobe/CreativeCloudApp.munki.recipe#L54-L55

For other possible child recipes I'm not really sure how one could handle the versioning of multiple "core" products besides simply returning something like "N/A" for version.

timsutton commented

I also wonder if we should consider normalizing all the input options in ccpinfo to a single case style, like how they were all lower-case snake-case before.

Is there any benefit to us having IncludeUpdates at all? We're already specifying a "shopping list" of items to add. I wonder what happens if you specify IncludeUpdates along with a single-item Photoshop CC 2017 pkg - will it automatically then include the those other updates, I wonder.

If it does, it leaves the possibility for an admin to build a package with non-deterministic versions of other updates like Camera Raw, but that it would not be obvious to the admin unless he/she knows where to go looking for it in the payloads pkginfo metadata.

mosen commented

The reasoning behind reverting the case of keys was simply less code.

I'll be testing IncludeUpdates further. The documentation implies that you can use either Product + HDUpdate or just Product with the updated version, which is quite confusing.

It also shows the IncludeUpdates key being used in combination with specific update versions, which doesn't make sense to me.

I'll return with testing outcomes.

mosen commented

IncludeUpdates = true/false with PHSP 18.0.1 produces an identical result.

timsutton commented

This issue was moved to autopkg/adobe-ccp-recipes#1