Suggestion: The command line and Unity Hub

It would be a nice addition to be able to do the following:

• Start Unity Hub from the command line pass it a unity project and it automatically initialises the correct unity version. possibly passing command line options on to the unity executable. This would make build automation and unity version management a darn sight easier.
• Tell hub to download/install/remove the latest/specific version through the cmdline, automate the world

Would love to see these options added

 

Upvote for Hub CLI. It could be a great build tool.

 

Up! We need this.

 

This is a fantastic idea, and would make our automated testing process so much easier.

 

Upvoting too! Would be immensely useful for automated builds!

 

Yes - we use Ansible right now for managing fleets of Jenkins build agents for Unity games. We do a lot of dorking around with .pkg files to get the right Unity versions on those machines. The hub could make that far simpler.

 

+1 to this! Would be super useful for a lot of automated build pipelines

 

+1 This would be amazing!

 

+1 would make my life easier in the long run

 

+1

 

This would make it so much easier for us during our CI and release builds. +1

 

+1

 

+1 this is a MUST!

 

In addition the commands mentioned above, we need the ability to license Unity via the command line. We manage close to 200 seats in an educational environment and are currently able to update our license keys via the command line. Unity Hub does not offer this ability. Worse yet, when Unity is installed via Hub, it no longer allows activation via the command line. This is even further exacerbated by the fact that Hub returns with a licensing server error 9 out of 10 times and just seems to never work on certain machines. See https://forum.unity.com/threads/lic...or-please-contact-support-unity3d-com.527145/

 

+1

 

+1

 

+1 as well. Great for CI but might make git bisect workable with editor changes

 

+1 from me too.

 

+1000 from me!

 

Really need this now that there doesn't seem to be any other way to get the latest Linux builds.

 

PLS PLS PLS,
we need this for professional workflows

 

+1

 

Digging through the Hub logs (in .config on linux and [UserAppDataFolder]\Roaming on Windows) yielded something useful:

https://public-cdn.cloud.unity3d.com/hub/prod/releases-linux.json
and
https://public-cdn.cloud.unity3d.com/hub/prod/releases-win32.json

Hub tries to refresh this, so I downloaded the linux releases. It contains the paths for all the binary downloads, which all seem to be archives inside archives with pretty predictable names. The Windows downloads are the same old executable component installers, so probably automatable on the CLI. The linux archives are just the actual binaries, so they'd need to be extracted to the appropriate locations and probably have the programs marked as executable. If/when I get this working, I'll update my dockerfiles and finally get new images (https://hub.docker.com/u/angusmf/) out for the missing 2018.2 releases.

---edit---

I've hit a dead end with the .pkg files. Can open them, but not parse them. Dropping it here and hoping we get some other way to do this stuff.

 

+1 on this.

Unity Hub has the potential to serve as the one-stop-shop for performing automated license management and download/installation of Unity. To reach that point, the following changes / features would be necessary:

1. A way to activate/deactivate a Unity license from the command line. This is needed in unattended scenarios (build systems). This can currently be done by installing a Unity Editor and calling that with specific command line switches to perform license management -- but it would be convenient to have the much smaller Unity Hub capable of doing this.

2. A way to install/uninstall a specific Unity version from the command line, with a specific list of components.

3. A way to install non-latest patch/fix releases. This is needed in environments where stability & reproducibility is important. For large teams, and for build systems of any size, rollout of new patch/fix versions should be managed centrally. As long as Unity Hub only offers the latest patch/fix release for a given major.minor version, I consider a non-Hub installation flow preferable in those scenarios.

(Since people have logged in with their Unity IDs when they use Unity Hub, the application could, in theory, also enumerate / download / install console-specific packages for those that are licensed. I understand that this would require use of other APIs than public-cdn.cloud.unity3d.com, and may cause backend scaling problems - but it could be something worth considering for the long term.)

---

Our automation (available here) downloads & runs Unity installation packages manually. We have resorted to manually collect & maintain a small index of download URLs here.

 

Wow, those are some hoops to jump through. This is really frustrating. I've been writing code of some sort or another for over 30 years. That's about how long there's been a computer at home. Of that, about 20 of it has been spent building (as in builds) and deploying (as in creating installs/packages and automating their delivery) software professionally, mostly for Windows. Why the difference in numbers? Because until you go work for somebody with funding, you have NO ACCESS TO REAL TOOLS. There's a huge difference in the kind of software you can create, even as a student or hobbyist when you have access to the tools that professionals are utterly reliant on. Unfortunately with Unity, I don't see any real tools available, hobbyist or not. To be forced to do all that work and still be tied to a single license running on a live Windows Jenkins agent? Madness!! I feel like I'm being pushed backwards in time...

 

Someone in the community has put in the effort to automate discovery and installation of Unity versions: Check out https://github.com/DragonBox/u3d - it looks like it solves most of the problem until the day Unity builds an official solution. From what I can tell, u3d does not do license management, nor discover/install console packages.

(u3d is a combination of a web scraper that locates unity versions / download links, an index JSON with the results on GitHub pages, and then a commandline utility for downloading/installing Unity versions.)

Agreed. I ask our Unity business contact for info on "build machine licenses" every couple of months. Nothing concrete has materialized so far though.

 

+1

 

I'd like to be able to do these things on the command line:

• Activate a license
• Return a license
• Install a specific version of Unity (with a list of components)

 

Looks like we will get CLI in 2019.1, as announced at Unite LA!

 

Not through the hub unfortunately but this already works for us today:

Code (CSharp):

1. SET UNITY="C:\Program Files\Unity\Hub\Editor\2018.3.5f1\Editor\Unity.exe"
2.  
3. %UNITY% -quit -batchmode -buildTarget %TARGET% -serial %SERIAL% -username %USERNAME% -password %PASSWORD% -nographics -CacheServerIPAddress 192.168.2.124 -projectPath %PROJECT_PATH% -logFile -executeMethod BitStrap.UMakeCli.Build target:%TARGET% path:%DESTINATION_PATH%
4. SET ERRORCODE=%ERRORLEVEL%
5. %UNITY% -quit -batchmode -returnlicense
6. EXIT /B %ERRORCODE

All CLI options available here: https://docs.unity3d.com/Manual/CommandLineArguments.html

 

This is what I use today, but I'd like it to be done via the hub. (or better yet, just make licences per account instead of per-machine)

 

+1

 

Super need this feature +1

 

Another thing related is, not only cmd. I would like unity and the hub could be command with url link schema

Like a unitypackage that would open assetstore tab in unity. If we could open project by clicking a link unity://{projectname} or add package from the browser with unity://packages/{github.com/project.git} it would be great

Already suggest in this https://forum.unity.com/threads/communicate-with-editor-from-unity-url-scheme.549520/

 

This is an important feature for easing lots of unity scripting +1

 

Agreed, this would make CI much easier.

 

@mathieub Any updates here? This is such a needed feature, and it's been a whole year since we've heard anything!

 

I saw new Unity Hub beta 2.0 but as I understood from roadmap session command line will be added only 2.1+ version. Is that right?

 

+1; it would greatly simplify build server setup

 

+!1That would be really helpful

 

+1 Been waiting for this for build machine automation

 

Command line arguments are critical for me and I can't use Unity Hub until they're supported. I have to launch Unity with -force-glcore, otherwise resizing viewports causes it to crash on my work laptop.

 

This will be great I hope it will come soon enough

 

@AbrahamDUnity What about open file by extension and open hub by schema url?

 

@AbrahamDUnity I have made a post about that here

https://forum.unity.com/threads/communicate-with-editor-from-unity-url-scheme.549520/
and post here
https://forum.unity.com/threads/please-let-us-open-unitypackage-with-unityhub.639244/
also with detailed comment here
https://forum.unity.com/threads/win...-be-handled-by-which-exe.290911/#post-4645888

There was 2 feature that I would like the hub to handle. First is the unitypackage file. It should be registered in windows registry to always open by hub

Copied from the comment

Second. It was my wish for such times that unity should be able to invoke its command from browser. In the same way as "Import package" button in assetstore website that could launch assetstore window inside the editor app
Because the browser could logged in the webservice provider, such as oauth provider, and get the data from any webservice. I wish I could create admin page in browser that could make a link, such as

<a href="unity://projectA/menuA/commandA?someData=xxx">Call menuA/commandA in unity editor</a>

to communicate with local unity editor from the browser instead of creating httplistener or webserver inside unity

But also the same as problem of unitypackage above. One machine could have many version of unity. But the hub would most likely be single. So this feature too should just be handled by the hub in the same way as unitypackage above

In fact. The url scheme could be treated in the same manner as the hub treating command line too

 

@AbrahamDUnity If security would be concerned I think we could just make it like this

We just have another attribute that would specifically register the path for url scheme in the project. So it couldn't invoke any command freely. The url could invoke only specific function we intentionally registered by attribute

Code (CSharp):

1.  
2. [URLHandlerAttribute("path/to/foo")]
3. static void Foo(string query) => DoSomething(query);
4.  

Code (JavaScript):

1.  
2. <a href="unity://path/to/foo?someData=xxx">Call Foo in unity editor</a>
3. <a href="unity://path/to/bar?someData=xxx">
4.     path/to/bar not exist in project
5.     so it can invoke hub to select project but will not do anything more
6. </a>
7.  

And if the command that should be invoked is not directly in the project but was inside the package. We could have a prompt windows for more security