Bug running unity in batch mode

I am running into a bug that is resulting in an internal compile error, which occurs when I run unity in batch mode. This is important for our automated build system.


Here are the reproduction steps.

1. Open an existing project in Unity.
2. Close Unity.
3. From the Apple Finder window, locate a code file that is part of the project that was just opened. Delete the code and corresponding meta file.
4. Open up the console window on your Mac, so that you will be ready to view the Unity Editor output log.
5. Open Unity from terminal, using a command that looks something like this: ./Unity -projectPath /depot/ProjectName/ -batchMode –quit
6. Now view the console log, and you should see a compiler error that looks something like the following.

-----CompilerOutput:-stdout--exitcode: 1--compilationhadfailure: True--outfile: Temp/Assembly-CSharp.dll

Compilation failed: 1 error(s), 0 warnings

-----CompilerOutput:-stderr----------

error CS2001: Source file `Assets/ExampleFIle.cs' could not be found


Where “ExampleFile.cs” is the file that has been removed from the project.


It appears that Unity thinks ExampleFile.cs still exists, and it starts compiling the code before it recognizes that this file is no longer a part of the project. I ran a diff on the Library folder before and after this file removal, and there were two files that differed: assetDatabase3, and guidMapper.


Consider how this works for an automated build system. Let’s say a programmer deletes a code file, submits his changes, and then kicks off a jenkins build. If that jenkins build then runs Unity from the command line, in batch mode, it will result in the error above, which means the build will fail.


There are two workarounds that I see: 1.) Delete all of the unversioned files, before doing the build, so that the Library folder gets regenerated. Or 2.) Run Unity twice. The first time it will update the assets, and the compilation will fail, and the second time the compilation will succeed. The second option is pretty hacky, and will make the build log output confusing. And the first option is very time consuming. Rebuilding the Library folder takes about 20 minutes for our project.


I would think the order of operations would be: Update and compile code -> Import assets. But it seems like code is considered to be an “asset”, in this pipeline.

 

I'm seeing similar problems, both when removing source files ("error CS2001: Source file XXX could not be found") and when adding new files whilst modifying others to use the contents of the new files (I get compile errors that should not be possible, but look like they are being caused by the new files not being 'ready'). Looking at the logs, the compile errors come before the new files are updated/imported. A second build (without changing the source) fixes things. Opening in editor doesn't seem to suffer the same problem - just running in batch mode.

I searched for case 703290 on your fogbugz tracker but couldn't find anything. It this issue still ongoing? I'm seeing it on Unity 5.2.2p3.

 

I've also found this bug which seems to be the same issue; someone from Unity QA replied in May this year to say it has been reproduced, but hasn't mentioned a fix. Has any kind of fix gone in?

https://fogbugz.unity3d.com/default.asp?560137_5p90morai1utgu6o

 

Any update on this issue? @alexkring, did you try removing less files than the whole Library? For example, deleting the Library/ScriptAssemblies folder? We're also looking for a better solution then running the build a second time automatically if there "was" a CS2001 error the first time.

 

Hi team,

Has there been any update on this thread? We are also facing the same issue as wondering if there is a known ETA for this to be resolved.

Thanks.

 

I reported this bug again since similar issues have been closed (incorrectly) - it's bug 759704. Unity haven't replied.

I'm still finding this an issue, in 5.3.4f1. Even building twice sometimes doesn't work - despite the 'problem' assets appearing in the logs as having been processed.

 

This is still happening in 5.4.1p4, though it does seem to be slightly more reliable after the 'fix' from 5.3.5. I can get it to happen 100% if I switch platforms between batch mode invocations.

I have an example repro here:
https://github.com/hymerman/unity-delete-script-bug

And I have just submitted a bug report. Again. (BenPlaysport is me too).

 

Still an issue in 2017.3 and earlier (didnt test 2018 yet)

 

Yes, I continued to experience this on 5.5, 5.6, 2017.1 and 2017.2. I've just upgraded to 2018.1 but don't expect the issue to be fixed.

I've updated the issue I logged several times but Unity can no longer reproduce the issue. I can't generate a minimal repro - the issue goes away if I start deleting large assets. Some point soon I will submit our entire project to Unity to see if they can reproduce and fix.

This is the #1 issue that's destroying my team's faith in our automated build process! I hate having to say "wait for the build to go green before going home" if I have to also explain "... except if a programmer checked in new source files and you see an error message that looks like this, in which case you should trigger the build again manually" etc etc.

 

Confirmed - it's still happening in 2018.1.0f2. I'll see if I can find time to upload the project as a bug report... All 33GB of it

 

Still happening in 2019.2.5f1. It really affects our continuous integration.

 

Oh dear Since my last message we took several more versions, all affected (up to 2018.4.2), and also we started paying for Unity support, who responded well - the issue is reported fixed in 2019.2. So it's disturbing that you're still getting it! Any more info? Is it when adding/removing/modifying files?

 

Yes, it happens when we refactor or move code around. Like moving a Cs file to a different folder. That usually kills it.

 

Could you report it as a bug and post the bug number here?

We have Enterprise Support, if I can point at a bug number then I can open a new ticket to tell them it's not fixed yet, and it'll get looked at much more quickly. Full attribution to you, of course We haven't yet upgraded to 2019.2 so haven't been able to verify the fix on our project... it'd be good to report it and get it fixed before we upgrade