Hello, I am a bit confused by the UI when trying to copy addon settings from one bundle to another.
My current understanding is that each bundle has at least two variants, Production and Staging, which each contain a copy of the settings. When in developer mode, I noticed that the copy settings UI allows you to choose a source bundle and a source variant, but the variant list includes other dev bundles:
Technically a bundle does not have its own settings, but addon versions have settings.
The addon version settings are per variant, where the variant is Production, Staging or any Dev variant. (Dev variants are special in that regard in that they are actually variants tied to that bundle - right @martin.wacker ?)
Knowing the above, when picking a “Bundle” with a “Variant” to COPY from it basically means to copy that variant’s settings for all the addon versions in that bundle.
The selection of the bundle there is mostly so that you can quickly copy over all settings from a variant from all its addon versions there in one go.
But you can also copy just for an addon version if you right click the Addon name in Studio Settings:
That way you can explicitly copy from a variant picking a specific addon version:
I feel like that UI is the best way of understanding that the settings are stored: per variant PER addon version
So variant Production may have settings for:
maya 1.0.0
maya 1.0.1
maya 1.0.5
And by no means are the settings anywhere stored on a bundle. They are only per variant, per addon version.
Pro tip: that “pick a specific addon version from a variant” trick to copy from also works with multiselection. So you can technically select all addons, right click the addons in Studio Settings and do “Copy settings from…”
Thanks for the information! I’m slowly but surely getting closer to wrapping my head around this
A couple more questions that follow from your responses:
If I create a new dev bundle, veena_bundle_dev1, does that mean that every single version of every single addon on the server now has a veena_bundle_dev1 variant? Or is the variant only added to the addon versions that are specifically used by this dev bundle?
And second question, if I create a new bundle without copying any settings, and it is not marked as production, staging or dev, what settings variant of the addon versions does it use? Does it default to use the production variant of each addon?
Sort of, yes. It’s best to think of it that way because if you’d “switch” to a new addon version in your dev bundle the old version will still keep its settings. So technically even addons outside of that bundle will have settings.
However, the settings per addon version only store the overrides as far as I know. So by default there technically are no ‘settings’.
It doesn’t have settings. That bundle, has no settings - only variants have. As soon as you mark it production, staging or dev then it’ll (sort of) start having a variant of settings that become applicable, yet even then - the bundle has no settings, just the variant happens to have settings for the addon versions in that bundle.
This is also why when on the Studio Settings tab for example, you can only display the variants and see their addon version’s settings.
Another way to visualize it, settings are like:
production
ayon-maya 0.1.0 → 2 overrides
ayon-maya 0.1.1 → 0 overrides
ayon-maya 0.3.0 → 1 override
ayon-nuke 0.1.0 → 1 overrides
staging
ayon-maya 0.1.0 → 0 overrides
ayon-maya 0.1.1 → 0 overrides
ayon-maya 0.3.0 → 1 override
ayon-nuke 0.1.0 → 0 overrides
And similarly continuing per dev variant with a similar list.
One could argue that this state is confusing:
Because even though it currently is not in a bundle, it may still have overridden settings for addon versions if e.g. they were set before. Basically the addons list on the left there “filters” the listed addon versions to display settings for based on the active bundle the variant is applied to.
Thanks, Roy, this makes more sense now.
I was thinking of settings as something that exist by default, which I think caused confusion in my mental model of this, but it’s more logical if you think of them as overrides that don’t exist a priori.
(Chef’s kiss)
