Required API for our CI/CD setup

Might have missed some existing API, but in any case what we need is the following:

• Check if bundles for a specific platform are already built
  • Don't build new addressables bundles on our CI/CD server if they already exist.
  • Do not rely on developers to check them in.
  • Do not rely on developers to check in the correct plattform (e.g. WebGL but our Integration Tests run on StandaloneWindows64)
    
  • Rebuild them iff necessary - as Integration tests can not be run without them.
  • Building takes a long time, avoid any unecessary build.
• Select and Change the current Addressables Profile
  • Do not rely on developers to check in the correct one. E.g. Remote is selected, but Integration Tests require a Local Setup
• Change between Fast & Packed Mode
  • I would like to keep most test configurations in fast and test only very specific pre-deploy tests in packed.
  • Building takes a long time, avoid any unecessary build. Yes. I repeated that one

 

For this, I will say that the scriptpable build pipeline SBP supports caching all build steps. And that cache can actually connect to the Unity cache server if you set one up. So I would argue your first section of requirements should be replaced with "build every time, and rely on SBP to do so effeciently"

I say this for two reasons. One, it should work. Two, there's no way to know if bundles are valid and up-to-date without doing most of the build. The process of "check if existing bundles exist/are-valid and build what needs building" is the primary directive of SBP.

This line should work:

Code (CSharp):

1.  
2. AddressableAssetSettingsDefaultObject.Settings.activeProfileId = AddressableAssetSettingsDefaultObject.Settings.profileSettings.GetProfileId("SomeCoolProfile");

This one's a little trickier. The current mode is exposed (
AddressableAssetSettingsDefaultObject.Settings.ActivePlayerDataBuilderIndex) but it's exposed as an index into your List<> of builders. Which is a little unreliable to set. For now, it should work for you, but long term we may need to add a more robust entry point.


Hope that helps.

 

That helps A LOT

 

@unity_bill I just checked and I had enabled the Cache Sever already a long time ago. However building the bundles still takes like 10-20 minutes and it looks like it does so without the Unity Cache Server as well (tested "local" and "remote" with the node.js based version to find out if there is a difference). This increases the time from running the configuration from 2-3 minutes to 23 minutes (almost 10x as long with some slight exxageration). Is there any way to verify the caching works? I cannot see a difference when disabling it and it looks like it is rebuilding all bundles completly anyway even when the only change between two commits was something minor like an added Debug.Log() which should result in the two commits beeing completly compatible from the perspective of the Asset Bundles.

Edit: Okay the editor log shows each interaction with the cache server. Still it is strange that bundles are rebuild from scratch (based on the time) when nothing changed that should affect them

 

Likely also needed for anyone who wants to do something with the groups:

Code (CSharp):

1. AddressableAssetSettingsDefaultObject.Settings.groups

and for anyone wanting to change the mode for the playmode

Code (CSharp):

1. AddressableAssetSettingsDefaultObject.Settings.ActivePlayModeDataBuilderIndex

@unity_bill I noticed something weird, not sure if a bug:

correspond to the indices 0,1,3 (as visible from the diff when changing it) - I'd expect 0,1,2 or 1,2,3 but 0,1,3 looks unexpected.

 

Sorry, I might have missed something. How do you actually cause the addressable bundles to be built from script as part of a CI build?

 

@dave_thrive, in short

Code (CSharp):

1.  
2. // Enable groups you want to include
3. foreach (var group in AddressableAssetSettingsDefaultObject.Settings.groups){
4.   var schema = group.GetSchema<BundledAssetGroupSchema>();
5.   if (schema != null)
6.     schema.IncludeInBuild = IncludeInBuild(group);
7. }
8. // Set profile
9. var id = AddressableAssetSettingsDefaultObject.Settings.profileSettings.GetProfileId("someProfile Name");
10. AddressableAssetSettingsDefaultObject.Settings.activeProfileId = id;
11.                      
12.  
13. // Set Packed Mode, find index by changing it in the ui, press ctrl+s and see changed files in vcs
14. AddressableAssetSettingsDefaultObject.Settings.ActivePlayerDataBuilderIndex = 2;
15. AddressableAssetSettingsDefaultObject.Settings.ActivePlayModeDataBuilderIndex = 2;
16.  
17. // Build
18. AddressableAssetSettings.BuildPlayerContent();

 

Thanks, that's great

 

The reason for the oddity in indexing is that the AddressableAssetSettings object has one list of DataBuilders. DataBuilders have an interface on them that can be queried to see if they can create the desired kind of build result. The UI for both PlayMode Script and Build Script loop that list of DataBuilders asking "can you build what I need?". In your case, your list was [fast, virtual, packed-player, packed-playmode]. So your `ActivePlayerDataBuilderIndex` is probably 2.

We do this as users can create custom data builders that could actually build for both. Or there could be data builders returning some third type of result that our UI doesn't care about.

 

Would be great to have a more CI-friendly API here I still don't get how to know how to know which index I need to use other than just by putting a break point into the editor script, run manually, see what's the index and then put that index as a const into my editor script.

@unity_bill any planed improvements here?

 

Is there any way i can change the Addressable Asset Group's build path and load path via script??

 

Code (CSharp):

1. [SerializeField] ProfileValueReference m_BuildPath = new ProfileValueReference();
2. [SerializeField] ProfileValueReference m_LoadPath = new ProfileValueReference();
3.  
4.  
5. AddressableAssetGroup group; // the group to modify
6.  
7. // Get group schema, because the paths are stored in the schema and not in the group
8. var schema = group.GetSchema<BundledAssetGroupSchema>();
9.  
10. // Change paths with SetVariableById:
11. schema.LoadPath.SetVariableById(settings, m_LoadPath.Id);
12. schema.BuildPath.SetVariableById(settings, m_BuildPath.Id);
13.        
14. // Change paths with SetVariableByName:
15. schema.LoadPath.SetVariableByName(settings, name);
16. schema.BuildPath.SetVariableByName(settings, name);

 

Thank you @Peter77 Its working !!!!