koobas.hobune.stream
Setting up a custom build system - linux, headless build machines, licenses
Do build machines need normal licenses?
If we are Pro users, how do we run extra build machines? Do we need to purchase extra licenses for those build machines? (Or do we re-use licenses from regular users? What if most people on the team already are using their pro licenses both at their workstations and their laptops, to be able to work remotely at times?) Is there some special form of license for build machines?
Background
I am looking at setting up our own build system, but am looking for some tips and pointers.
We have already tried Unity Cloud Build. It is simple, but it does not fit our use case that well; we use Plastic Cloud for version control, we want quick turnaround for builds, we want custom build steps (example: apply Steam DRM wrapping) before and after the game package gets built by Unity. Therefore I am looking into setting up a custom build cluster.
I prefer not running own hardware if possible.
I prefer being able to scale up/down the number of build machines with a couple of commands.
I like container technology (Docker/Kubernetes). Container technology works best on Linux OS.
I like Jenkins and Buildbot.
I understand that physical Mac machines are needed to build for Mac App Store & iOS store.
I have managed to get Unity installed on a Linux VM in Google Compute Engine, and license activation using a Pro account, thanks to these threads. Still, the licensing questions remain. If there are reasonable solutions for the licensing situation, I intend to continue with pushing Unity into Docker containers which are nuked and rebuilt on regular schedule.
After talking with Unity staff, the answer is currently: "Use the 2nd seat of your current licenses for your build machines". (Each pro license is for 1 user on up to 2 machines/seats) There are no special build licenses available, nor any way to build a player without activating a license on the build machine.
This means that yes, a build cluster can be set up on a bunch of VMs in Google Cloud/AWS/Azure - but the machines should be long-lived. Setups where containers/VMs are dynamically created and destroyed on demand or according to schedule won't work.
Here are a couple of options which should work though:
Install both Unity and the build system directly onto VMs. Use classic tools like puppet/chef/ansible to manage what is installed and running on each VM. Run build jobs directly on each VM.
Install both Unity and the build system directly onto VMs. Use classic tools like puppet/chef/ansible to manage what is installed and running on each VM. Run build jobs within containers on each VM.
Install Unity directly onto VMs, deploy build system and build within containers on said VMs. Run build jobs within containers. Use tools like puppet/chef/ansible to control which Unity version is installed on each VM; use container tech to control the build system and its outputs.
Start up containers on VMs, perform Unity and build system installation within these containers. Run build jobs within these containers. Use puppet/chef/ansible to manage what is happening within each container.
Docker/Kubernetes will not give you auto scaling. You do get good monitoring of the parts that are run within containers. As long as Unity is installed outside of the container, you can also easily throw away the container to get a guaranteed clean build. On the other hand, it means you have yet another layer of complexity in your infrastructure.
