Automated Builds - Addressables NOT Being Built (Variants Example; code included)

Our 'Build Maker' code:
https://gist.github.com/ArthurD/c2ca0d77166e55dc083d6f097426045b#file-runbuild-cs-L35

A few methods are left out but they're pretty self-explanatory, it's generally just options/argument passing & compiler directives since we run this code is headless, via CLI with the appropriate domain-specific args for our game. The entry-point method in our code is MakeBuild_CLI() -- which simply parses CLI args and then calls MakeOneBuild() with the proper params based on what was passed in via CLI.


The Problem: Addressables are just not being built.
The build runs & completes successfully -- no errors in the editor log during the build. The build is at the expected location but the StreamingAssets dir does not have "aa" in it as we would expect, and then running the game obviously ends up failing when it attempts to load Addressables that aren't there.


The Issue/Question: Why are the Addressables not being built?
In our code (linked above), why does L67 and L68 not cause the Addressables / asset bundle to be built -- how/why can it not cause them to be built?!

Thank you in advance for any help/guidance.

FWIW, I've screwed up & already merged this stuff into our "edge" branch -- so we're a bit stuck right now, or I need to do some reverting, heh. On the positive side, our two builds only take 5-minutes (down from nearly an hour!!!), but they don't work because Addressables aren't being build -- so it isn't overly helpful / obviously we want fast builds, but we need them to be working / deployable, obviously... =D

Edit -- Our config/version info is as follows:

• Editor: 2019.4.23f1 (macOS & Windows; same result w/ 2019.4.22f1)
• Addressables: 1.16.15. (also tested w/ same result on 1.17.13)
  
• Scriptable Build Pipeline: 1.15.1

 

I took a look at the github file. I don't really see anything jumping out as wrong. The first thing I'd check is the Library/com.unity.addressables folder. Our build just puts stuff there, then during a player build we copy it into StreamingAssets (then immediately delete it). So if things are in the Library folder, then the copy step is breaking. If nothing's in the library, then the build step is breaking.

If there's a catalog, but no content, then either the content build is broken, or you are accidentally using a profile that is set up for your content to not be local. All in all, I'm kinda just guessing at what could be wrong, but hopefully pointing you towards some debugging steps that will make the issue clear.

 

We have 'vendored' the Addressables package (to restore the 'warn, but always return asset [even if duplicate load]' functionality of prior versions) -- so in our project the package is located at: `PROJECT_DIR/Packages/com.unity.addressables`

When that's the case, is the data built into Library/com.unity.addressables/ still -- or is it built in the local/vendor'd dir?

 

Nvm -- it's built into the Library/com.unity.addressables/ folder regardless of vendor'ing the package.

The data is being written it appears, though for the wrong target platform. Our 'Mac' build is outputting Windows addressable assets into the

Library/com.unity.addressables/

folder. It's not being copied (or deleted) after the build finishes, though.

 

Ah, ok, I see it now. You have a custom command line argument called "tgt" that you are keying off of to set the variable `target`. You then pass that into BuildPlayer. This will switch the editor to that target during the build.

There are two problems with this.
1. it's slower to change target mid build as opposed to launching the editor with that target
2. as of when you ask addressables to build, the editor is not set to the correct build target.

Instead use the actual unity argument of "-buildTarget <name>" found here https://docs.unity3d.com/Manual/CommandLineArguments.html. If I remember right, you can then read that value with this https://docs.unity3d.com/ScriptReference/EditorUserBuildSettings-activeBuildTarget.html


I think there's also a way to call some API just before building addressables to switch the engine over, but again, the recommended way is to launch the editor with the right context.

 

We use both -- it's duplicative (legacy reasons), but the 'TGT' one is for our internal "defines" stuff. We also set the Unity -buildTarget flag, if we didn't then the build wouldn't be for the appropriate platform.

We have it setup like this specifically to avoid having to change build targets when making builds (for performance/speed reasons) -- each build target has a dedicated project dir/folder locally that we use to only build for that platform.

Concrete Example:
/ProjectName-WINDOWS/ -- Only used for building Windows builds via CLI.
/ProjectName-MAC/ -- Only used for building macOS builds via CLI.
/ProjectName/ -- Our 'actual' working directory; we run the editor GUI against this project dir.

The command we use (note it DOES have -buldTarget CLI arg):
"/Volumes/Main Data/Unity Editors/2019.4.23f1/Unity.app/Contents/MacOS/Unity" -batchMode -quit -executeMethod "RunBuild.MakeBuild_CLI" -buildTarget "Win64" -projectPath "/Volumes/Main Data/Projects/projectDir-WINDOWS" -options "1408" -buildDate "637527043200000000" -tgt "WIN" -branch "Edge"

So, AFAICT, we are setting the build target correctly (via the Unity CLI arg) -- and Unity is building the project as expected for that platform -- but Addressables is still building for the wrong platform.

 

I've now verified via logging that the build target is being set correctly -- and I even attempted to "re-set" it correctly (though it already is set correctly) via the following code (only the first 2 lines are new/added).

Code (CSharp):

1. Debug.Log("Target:  " + EditorUserBuildSettings.activeBuildTarget.ToString());
2. EditorUserBuildSettings.SwitchActiveBuildTarget(BuildTargetGroup.Standalone, target);
3. AddressableAssetSettingsDefaultObject.Settings.ActivePlayerDataBuilderIndex = GetSettingsIndexForAddressables();
4. AddressableAssetSettings.BuildPlayerContent();

The result is still the same -- the macOS build has the Windows Addressables data in the Library folder, the data doesn't actually get copied to the build's StreamingAssets dir though, nor does the data end up getting nuked from the Library folder. The data is being written for sure, it's not "leftover" from prior builds or anything, the file creation datetime shows that the data is "newly built" data -- but obv. for the wrong platform.

 

Hi folks,

Did you ever find a workaround to this issue? We seem to be encountering a similar problem ourselves.

 

We ended up just "parallelizing" the builds -- one whole project dir per BuildTarget (ie "ProjectName-MAC" and "ProjectName-WIN64", etc) -- and then running our custom build maker via CLI cmd, each with its own editor instance.

It basically removed this issue, since each project dir is only ever used for that BuildTarget -- it also dramatically sped up our builds, and not just because they're running in parallel (that does seem to help some though), but I believe it's mainly because switching BuildTargets is a relatively expensive procedure on medium-or-larger projects (read: project with lots of assets).

Our 'BuildMaker' code (the code that accepts the CLI args => static method call) essentially just does two things:

1. Runs some git commands to ensure that the working dir/SHA1 in the user's working directory [from which the cmds were generated] is identical to the build-directory's repo. Entails switching branches if on wrong branch + fetching from git remote if needed, etc. (if parity is still not achieved by then, it throws/alarms/doesn't build - to prevent the different platform builds from having been made w/ disparate data or code).
2. Runs the actual build.

Basically, the 'workingDir' is wholly distinct from any of the [per-platform] 'buildDirs'. The workingDir instance [where we actually work within the unity editor] has a BuildMakerWindow, has some configuration options, and then you click 'Get The CLI CMDs' -- it outputs the commands via Debug.Log -- then we manually paste them into a console.

I know it's not a direct answer, but hopefully it helps -- is definitely the fastest way to build for multiple platforms. We went from ~6hrs to build against 3-4 platforms, to now is around 15-30 minutes for the same number of platforms!! =D