Bug Silently fails when building project from cmd line

I'm trying to build a project using unity-editor-2018.1.2f1 from the command line on a headless machine. Unity Editor is silently failing when running the command below.

Based on the Editor.log output below, there may be a couple bugs here:

1. CreateDirectory fails, yet it appears to be created. Perhaps it fails because it already exists causing the failure message?
2. The editor is attempting to display a progress bar when run from command line with -batchmode. (and -nographics, for that matter, but -batchmode should be enough according to docs at https://docs.unity3d.com/Manual/CommandLineArguments.html )
3. "No protocol specified" - This may be an error message due to the editor trying to use an X session when it shouldn't because of being run in -batchmode.
4. The editor failed to activate the license via the -username and -password command line parameters.
5. Ultimately, there was no error output, leaving the customer confused as to what failed (unless they happen to find the Editor.log).

$ unity-editor -nographics -username myusername@gmail.com -password 'password' -quit -batchmode -projectPath . -buildLinux64Player ./out

$ cat $HOME/.config/unity3d/Editor.log
CreateDirectory '/home/user/.cache/unity3d' failed: (current dir: /home/user/game)
DisplayProgressbar: Unity license
[0714/113546:ERROR:browser_main_loop.cc(161)] Running without the SUID sandbox! See https://code.google.com/p/chromium/wiki/LinuxSUIDSandboxDevelopment for more information on developing with the sandbox on.
No protocol specified
Cancelling DisplayDialog: Failed to activate/update license. Timeout occured while trying to update license. Please try again later or contact support@unity3d.com
This should not be called in batch mode.
(Filename: /home/builduser/buildslave/unity/build/Editor/Platform/Linux/EditorUtility.cpp Line: 238)

 

Is it a bug? Are you using personal? I can't say what happens if using a paid version, but for Personal, it's tricky to get the licensing to work. And for some reason you still need x, even with no display. I stole a lot of it from https://www.robinryf.com/blog/2017/09/30/running-unity-inside-docker.html
but I have automated builds working. Here's a little example:
https://gitlab.com/angusmfdotcom/HelloBuild

Actually running the build looks like this:

xvfb-run -a --server-args="-screen 0 1024x768x24" [path_to_unity_editor]/Unity [your Unity CLI args here]

If you want to use what I've done or take it as a starting point, the images are on docker:
https://hub.docker.com/u/angusmf/

And the Dockerfiles are on GitHub:
https://github.com/angusmf

 

I'm using personal, yes.

I would say it is a bug, yes -- a few bugs, in fact. Unity editor silently fails when simply trying to build a project from the command line. Unity editor fails to accept the username/password via command line to activate/validate the license. Unity editor requires an X server to simply compile/build a project.

Also, there is no output, so it is a bad and confusing UX for customers (particularly for those who won't know to go digging into the editor's log files to debug the problem).

Nifty, but in my case, I can't simply run docker or an X server within the build environment I'm considering.

Where I come from, it is absurd to require a running X server to compile/build software!

 

The validation failure is intentional, I think. They want to force you to go through the questionnaire regarding personal use. But I also figured maybe Pro or Plus might not have this issue with requiring an x server.

Not disagreeing with you that this is a pain or making excuses. Just offering workarounds. Docker is not required, just xvfb. Sorry that's not possible in your automation environment. Personally, I can manage to run docker and/or an x server on anything that will run Unity, so...

Again, not making excuses, but I wouldn't be surprised if making automated builds easier is not a high priority, since that presumably reduces demand for their cloud build services.

This stinks, but I believe it's documented with the CLI that if you pass the logfile argument, you also get output to stdout.

 

Also, once you've activated, you can simply copy the license file into the correct dir, as I do in my example. I keep it in a private submodule.

 

One last thing. In order to get Unity to work on bugs, you MUST report them. And if you're going to post in the forum about a bug, they seem to really like it when you post the issue tracker ID# as well. Smiley face.

 

That output is empty. There are two different things being mixed up, the editor's log file (that goes in ~/.config) and the stdout that you can redirect with the -logFile command.

Thanks for that. Didn't realize they had a separate bug tracker.

 

K, let's clarify then. When you specify the logfile path, you get the logfile output to wherever you specify AND you get stdout to the console -- or wherever you redirect that to. That isn't what the doc actually says:

The fact is, I didn't see any output to stdout without specifying a log path. That could be a bug, but at least the documentation should give you a better idea what to expect.

I didn't hunt around for a long time for answers to this x server thing, though. Unity's responses and all the automation I've seen using the Linux editor make it pretty clear you gotta use x. I tried it without, it didn't work, so I put it in and moved on. I'd also just expect that anyone who can automate a build knows to go looking for log files.

Having to use the editor for builds is janky. Period. In the old days, the software company in question would eventually release the build tooling as a separate thing. Again, due to cloud build, I don't know that Unity will ever have a desire to do that.

 

This whole phenomenon is weird since I've tried building my project in multiple update/releases and it still doesn't work.

 

If you're still trying to activate personal on the cmdline with username and password, I don't think it will ever work. You need to interactively license it then either keep the license file in your build image, or copy it back in before each build.