Unity Licensing for Build Machines

Does Unity have any options for dealing with licensing on build machines?

I'm currently at a small studio that has a Mac Mini with Jenkins on it. Jenkins takes care of continuous integration, but in order for it to build Unity projects, we need to activate a license on that machine. Currently, this means that someone at the company needs to "give up" their secondary license install, which isn't ideal. Another problem: we're hoping to get a few more build machines, but it seems we'd have to force employees to give up their secondary licenses, or buy Unity Pro licenses specifically for those build machines.

Is there any solution besides buying more licenses for the build machines? Considering those machines don't have real people using them, and they use Unity in headless/batch mode, it seems to be a bit much. Has anyone else had to deal with this scenario?

 

Unity Cloud Build?

 

That's an interesting question. We do the same, build machines and even dedicated bundling machines. But given our size, we just get licenses for each. But for a smaller studio, that cost may not justify the return. The license is pretty clear when it comes to "users", I'd be curious what the official answer is as well.

 

@Aurore or @SaraCecilia might be able to shed some more light on this.

 

Isn't there 8 or 16 or more core machines that could do this? It'd be cheaper and likely faster too, certainly than the lot of you on MacMinis all buying Unity Pro licenses.

e.g. Link to multicore PCs or e.g. Multicore MACs

 

You may have misunderstood. He's talking about a separate computer(s) with unity installed that is automated, doing continuous builds (or other tasks). Builds and some tasks are done on it, so developers don't have to locally build each time. So if I make changes to the game, I commit them and either tell the build machine to build or it is automated to do it on schedule. Everyone else can just update their device to see the current build. Rather than pulling, building locally. Or for our bundle machine, if I commit asset changes, I can keep working and the build machine will create new bundles for all devices and push them to the server. It is very fat and convenient with multiple devs.

 

Hmmmm, that sounds like what I meant, developers committing changes to a server machine to do builds, those are built, pushed to the QCs & testers with their test devices, yah or nay with report back to the developers and on to the next bit of functionality.

However, I'm not sure what he means be secondary licenses unless it's for those Pro licenses needed for each Pro platform. He doesn't say what version of Unity but Unity Pro seems designed to enable that type of workload distribution and network storage sharing among properly licensed machines.

All that seems sub-optimal though. Are the developer machines beefy enough to do distributed headless builds locally on network storage while the developer continues to work in the Editor on the same machine? 4 or 6 cores should be more than enough of course with Macs if that means new HW for each developer it's like buying 2 Unity Pro licenses. They have to write the built scripts to built on the machine with the relevant Pro license is all after the changes are pushed via the network to their machine. I know Unity already does lots of lighting and other things in parallel. Or would even doing a headless build while still using the editor violate the license somehow? Don't know if they are on a fast lan or an iffy wan though but I guess they are already sharing large resources over that network. They get the additional bonus of redundant storage if the network files are copied to a local disk, built, and copied back.

Unity can tell them the allowable setups for such a thing since they have Pro licenses. I'd open a Premium Support ticket to get his team setup using their HW & Unity Pro licenses optimally.

 

Even with a fast machine it's not efficient to do locally. It would be possible, but no where near as fast and not without slow down, potential problems and hit on the network. You can easily run multiple instances of unity on a single machine, but if you have one in the background doing builds it will slow down even a fast machine. Especially if you have many or large assets (and/or baking), doing it across a network. Moreover, you would have to still have checks in place to ensure that changes don't occur to assets on the server by someone else mid build. A build server/machine handles all that if it is the one doing the builds. Also decentralizing adds risks and other challenges like different settings and platforms and scheduling and conflicts. And also, in our case, often folks making changes and doing builds aren't even using unity in the first place. Art or design may be submitting assets or data to be in the build.

I believe what he means by secondary licenses, is that unity allows two installs per person. So one or more users are giving up their second install to the build server(s). Meaning they can't, for example, have it installed on thier desktop and laptop.

 

Oh, I know it will cause slowness due to network bottleneck but on a machine with sufficient SSD storage and CPUs/GPUs it should fly. However Intel needs to step up their GPU design and give a bigger and dedicated bank of GPU memory separate from CPU memory. I think the better and cheaper solution that can be done now is to have the builds and packaging kicked off as needed by the QC / Tester. We're talking small potatoes here. What's that 15 or 30 minutes of build and packaging time on an app of the total of the many hours they should be designing, developing, and testing that app with? It's indicative of insufficient design time before development and testing begins.

If secondary licenses mean 2 installs per user then if Unity could elegantly switch back and forth without restarting between Pro and Free licenses by local license sharing between the Developers' editor machines and the headless build machines that'd seem to do the trick but the license should only be able to be shared between the specific developer that owns that license and the build process. I don't think logistically, for the hassel it would be for Unity to develop such a license sharing mechanism, they'd bother. Really if they are using Unity 5 Pro there is precious little that Unity 5 Free won't build on a shared built machine already. Just the custom splash screen is all they'd loose I think.

They can pay for Premium support ticket to learn how to better utilize Unity team tools that Unity Pro has. That Unity are adding a Team License for monthly sub to Unity 5 Free shows they have been already confronting this issue and have decided with Unity 5 the need to impede Unity 4 Free users from leveraging Unity 4 Pro features via team collaborations is gone because, except for the skinning and the splash screen, there isn't any.

 

If you want to run Unity for a build machine you don't need a special licenses but you will need an additional Pro license (if you're team is running Pro).

If you are also running Pro at the moment, you get 12 Months of Cloud Build for free with every license so I would suggest trying it and see if it fits your needs (if you haven't already), that would also mean you don't need to use up someone activation or buy a new license. https://build.cloud.unity3d.com/landing/

You can talk more in depth on what would be best for your studio with a Sales Contact http://unity3d.com/sales/finder

 

Hi @Aurore, thanks for the data! While we're intrigued by Cloud Build, our repository is currently ~24GB, so we'd have to use the enterprise tier, based on current restrictions. I may be able to reduce that repository size to make Unity Build an option - something that I'll consider. But currently, it makes more sense for us to have in-studio machines doing the build process. I'll pass along to the owners the notion of following up with a Sales Contact.

The idea of using developer machines is intriguing, but I don't want to use developer CPU during the day and interrupt their work. Additionally, even in batch mode, Unity will add an icon to the dock, and is slightly disruptive to the machine, so doing it on a machine being used by a developer would probably be inconvenient, at best. An additional snag, though a system like Jenkins CAN execute multiple jobs in parallel, is that only one Unity instance can be open when in batch mode (though I don't think this is a limitation in normal mode?).

Anyway, this is one of those scenarios where a viable technical solution just doesn't seem to work with the business model. When it comes to continuous integration, adding additional nodes to your "build farm" is a pretty common, distributed approach, but it's a more difficult option with Unity involved.

I am certainly biased, but a reasonable solution might be adding a third "build" seat to a license, which can maybe only be used in batch mode. But of course, I am also a customer who doesn't want to spend more money than I have to, so of course that sounds great to me . There are probably reasons that it isn't possible from Unity's perspective.

Anyway, thanks again for all the data! It seems that, for the time being, we'll have to continue using additional licenses to fuel our build machines. We'll try following up with Unity Sales and see if there are any other options we can pursue.

 

Cloud build is not suitable for all projects and is not without it's problems and limitations. Many of us don't want to upload a project when we can just build it locally.

 

You could also do builds using developers' machines at night when there is exactly 0 people in the office. Just instruct your team to leave computers on, only turn screens off and use some scheduling software, (Widows has one built-in, Linux has cron, not sure about OSX) so Unity can built in batch mode.

 

For most people, that's not an option. At that point you might as well do builds by postal mail.

 

Which is why I mentioned to try it to see if it suits their needs, since it's available for them to do so anyway.

 

Well, @kromenak isn't "most people" and until he (or she) chime in, we can't know if that wouldn't be sufficient.

 

I definitely appreciate the various suggestions for alternative solutions or workarounds to using dedicated build machines. I was mainly curious as to whether there is an "official" way to deal with licensing on build machines, since it seems like a problem that would come up frequently. It seems like the solution, at this time, is to just use secondary seats of licenses, or buy dedicated licenses for build machines.

I think that Unity Cloud Build, or co-opting developer machines during off-hours could certainly be good solutions for some situations, but they don't feel like great solutions in my case.

I'd love some way to run Unity in batch mode as part of my pro license, but even if everyone agrees that's a great idea, it would no doubt take a lot of time to implement!

 

It takes nothing to implement, it's just it isn't going to happen. All they need to do is include additional seats for command line only access for doing builds. I appreciate you get two licenses with a Pro license, which is really needed as you can't do everything from one platform but having a local build server is much better/reliable than cloud build.

 

Yeah, do I need 1 license per build machine? I currently have 6 (1 per platform, Windows, Linux, Mac, X1, PS4, Switch)
Those are very limited hardware in a 1U rack, with only a SDD. They have Jenkins running, pull a SVN changelist, compile in no graphic mode, then put the result on a FTP. The hardware of those machine is less than 500$ each.

Our game SVN right now is about 50Gb which creates an extra 25Gb library, and output an ~10Gb game build. Before we are done with our game, we except our depot to reach ~70-80Gb. We can't use Unity cloud service because clearly I don't have 10-12 hours to wait for your service to pull out our database. Just the initial library recompiling is an hour and half.

I'm really not a fan of 6x 25$ or 125$ per month, for licenses that only get used 2-3 times a week. And before you ask, if I was to compile those 6 platforms on my own computer, with the 1.5h of switching between them, and about another hour of compiling... I get waste a full day only doing 1 build for 6 platforms, while now I just remote desktop to 6 very cheap PC, and bam! An hour later my FTP is full of builds.

How about a license that are only for running Unity headless?

 

We're also facing this same issue... Unity Cloud Build is not a viable option for us. As we grow we'll need more build instances but with each instance requiring a new license, it's just not going to be sustainable having so many unused licenses burning a hole in our budget. It's an easy solution Unity, have batch mode only licenses!

 

You could use your own machines as build agents. Thats how we do it. But we are a small studio and we dont push more than a couple of pushes per day.

 

Any movement on this?

 

It took 15 years to get a simple copy-paste function in the inspector... Give them a couple decades to figure that one out.

 

@LightStriker: That's funny. Mean, but funny.

 

Perhaps, but this thread is already 5 years old. I got tired of repeating Unity needs the basic done first before doing flashy features.

 

It's an understandable frustration. Creating a focus on the essential is one of the principal challenges of any sufficiently large organization and it plagues many of the smaller ones, too.

 

...and I meant "mean" like "acerbic" not like "vicious".

 

No update on this from our end. We've instead had to purchase powerful build servers so we can run ~12 Unity instances at once on a single licence to take full advantage of each licence. We reached out to our regional sales person at Unity and they basally said no such licence exists and no decent discount can be offered. We've just decided to bite the bullet on this one

 

For my part, I wish they would just make UCB a viable component within a mature build pipeline by making it able to accept source as an uploaded artifact rather than pull it from a repo. Then I could just stop doing Unity builds on my own hardware altogether and the problem would go away. It wouldn't solve everyone's problems but it would solve the problem for a lot of people.

 

Thank you Richard

 

Can the floating licenses of a Unity Build Server be used alongside Jenkins for automated build and uploads ? Trying to find a cheaper alternative than having a Pro License on each build machine while keeping the flexibility of Jenkins

 

Ouch. Talk about over-engineering and over-priced.

"We need a license that can only be run in headless mode/command line."

"Here's a license server."

"... what?"

Anyway, since my original post, we found out that since we are working on PS4/PS5/Switch, we can't use "external" licenses. We need to use the licenses provided by Sony/Nintendo. A clusterfuck it continues to be.

 

So I have this scenario, I want to integrate a containerized Unity build process into our Azure DevOps Pipeline. I've automated the activation process and we'll be using a secondary Plus license for the build.

My question is whether I need to also deactivate that license once the build is done to ensure I can use it again on the next build?

Additionally, if the server on which the build occurs is different each time (different IP, different system) do I need to be concerned about my license being banned or limited by Unity's Licensing API?

 

Do i need multiple licenses to run multiple build jobs in parallel on the same machine?

 

Any news on declusterfucking this issue? We can't build for console on those license.

 

What counts as a "machine" in this context though. If running builds in a cluster in containers but assigning them to the same node is there some way the license server will know that they are running on the same node and act accordingly? Or is a container considered a "machine" for license purposes?

 

Do we have to buy the Unity Pro Build Server with the same Unity ID as our other pro licenses? In other words, can our new IT department create a new account and buy the build server without any effects on our existing licenses, but we can still use it? As I understand, our working pro licenses don't play a role in the chain of git <-> build pipeline with build server.

Can someone clarify this:

• With one build machine and one license I can build one project for multiple targets at the same time, because I can start concurrent build jobs – that’s correct?
• With one build machine and one license I can not build multiple projects at the same time. I need a second license for a second project.

Thanks!

 

This seems wrong. I have to install a licensing server which handles a floating license. That license will be activated during the build, so how can i run multiple builds in parallel without buying additional seats?

 

Do we need to setup the floating license server or do you have a managed service ? We currently have dedicated machines (Jenkins Nodes) for our build machines and we are looking for ways to scale up and scale down capacity. We want to dynamically provision Jenkins nodes based on the load.

 

So is the licensing per machine an intentional design? Or a technical limit with the licensing implementation you didn't feel like fixing?

Because server side multiple instances on bare metal is just crazily better cost wise. I can't imagine Unity not changing to per instance if people got smart here. Bare metal auto scaling is a thing now days and it's not hard.

 

Another year gone by...

When I said it took 15 years for Unity to get a copy-paste in the inspector. Finally got to try it. It's a broken mess. Should have known.

 

@superpig Any updates here? I'm trying to set up automated daily builds of my project in the cloud — is my only option paying $1800/yr for every 2 seats (with no need to manage any on-prem servers), or paying $600/yr per 1 seat AND I need to manage and host a licensing server?