Cleaning up the server?

We have implemented the addressables sytem and stored our addressable asset bundles on our server by building addressables through Unity Build Cloud and than upload them using FTP called by the post process of Unity Build Cloud.

But one thing isn't clear for me: How do I know which asset bundles 'belong' to which Unity build?
I see unique identifiers in the names of the bundles but I don't know how to figure out which bundles are obsolete.

We have a system where we can push new unity version to our customers so we know which builds aren't used anymore. So we like to make something that cleans up old bundles. But how to identify them?

Or maybe our approach is wrong and the addressables team has some different strategy in mind that I'm not aware of....?

 

Nobody knows?

 

Hey. I'm very new to this one too, but if I understand correctly, you should be able to see which assetbundles you need from your catalogue. If the keys and hashvalues in your catalogue correspond to one existing file, then you know that you need it. Basically what you need to do then is: get all filenames from your AB folder, check if they are inside your catalogue. All others can be deleted then.

Does this help you?

 

Thanks for answering. But this means I have to store all hash values from a build in our database and see if which ones are still used?
Maybe better to store the asset bundles in a unique (per build) directory. So when we know a build isn't used anymore we can delete the hole directory....

This would mean that, after UBC has build a new version, I have to find a way to change the RemoteLoadPath...

 

You can create unique subfolders for each build, but then you can have the ABs in different directories. For example you have a texture and create an AB out of it, when that texture never changes you *should* always get the same AB out of it (same hash, same CRC,...). Having that in multiple directories creates redundancy (which could be what you try to achieve, but that's up to you) and needs more webspace. If you have them all in one directory, the old file may or may not be overwritten (it's the same file anyway) without any drawback.

I don't know how exactly Addressable are working under the hood, but as you have to pass the asset catalogue into your client, the client will know which hash values it wants to have. It's all inside the asset catalogue. You can compare two asset catalogues and figure out which assets are new/changed.

 

I understand but the comparison should be done by our build management system which is running on the web and isn't Unity. In this system we can decide to to force an unity app update or decide that an app version isn't available anymore.
When we worked with asset bundles (the old way). We just changed the path to the asset bundles belonging to a particular build in the prebuild face of Unity Build Cloud and at runtime passed the url to the asset bundle system when initializing. But now we can't do something like that anymore.

 

It depends a bit on how you name your ABs. If you use a filename which related to the assetname (e.g. texture "MainAtlas.png" will be "MainAtlas.bundle") then yes, changing the folder for downloading is a valid way. You could though change the name of the bundle to its hashvalue (i.e. "MainAtlas.png" will be "<random hash string>.bundle") and then it doesn't make a huge difference if things are in the same or different folders, 'cause the hash value should ensure that the AB is compatible with old and new versions (else the hash would have changed).

For that hash as filename, you had to do some custom renaming for the old AB building system (there was only the possibility to add the hash to the filename, which would also work btw). With Addressables this is config option now that files are build with hashes as filenames.

 

You can still do that, and I do it in my project. See https://forum.unity.com/threads/loa...uded-in-the-build-itself.821943/#post-5454570

 

Another thing to bear in mind if you want to completely rebuild separate asset bundles for each build(differetn download URL, so to not reuse them if they haven't changed) is that you'll invalidate the clients asset bundle cache:
- When they upgrade the client they will have to download every asset once again.
- Depending on how you server the assets to the clients, this might come with a price. If you're not using a CDN ore some intermediate caching mechanism and you're charged for the traffic to your download server ... beware.

 

Thanks I will look into this!

 

Thanks I will consider different approaches.

 

You have a strong point here. Although the price isn't really an issue in our case, clients that need to download all the bundles again isn't what we want so I have to find another solution to remove 'old' deprecated bundles..