The latest in a series of posts on getting Unity Test Framework tests running in jenkins in the cloud, because this seems entirely undocumented.
To recap, we had got as far as running our playmode tests on the cloud machine, but we had to use the -batchmode -nographics command line parameters. If we don’t, we get tons of errors about non-interactive window sessions. But if we do, we can no longer rely on animation, physics, or some coroutines during our tests! This limits us to basic lifecycle and validation tests, which isn’t great.
We need our cloud machine to pretend there’s a monitor attached, so unity can run its renderer and physics.
First, we’re going to need to make sure we have enough grunt in our cloud machine to run the game at a solid frametate. We use ec2, with the g4dn.xlarge machine (which has a decent GPU) and the https://aws.amazon.com/marketplace/pp/prodview-xrrke4dwueqv6?ref=cns_srchrow#pdp-overview ami, which pre-installs the right GPU drivers.
To do this, we’re going to set up a non-admin windows account on our cloud machine (because that’s just good practice), get it to auto-login on boot and ask it to connect to jenkins under this account. Read on for more details.
First, set up your new windows account by remoting into the admin account of the cloud machine:
- type “add user” in the windows start menu to get started adding your user. I call mine simply “jenkins”. Remember to save the password somewhere safe!
- We need to be able to remote into the new user, so go to System Properties, and on the Remote tab click Select Users, and add your jenkins user
- if jenkins has already run on this machine, you’ll want to give the new jenkins user rights to modify the c:\Workspace folder
- You’ll also want to go into the Services app, find the jenkins service, and disable it.
- Next, download autologon https://docs.microsoft.com/en-us/sysinternals/downloads/autologon, uncompress it somewhere sensible, then run it.
- enter your new jenkins account details
- click Enable
- close the dialog
Now, log out of the admin account, and you should be able to remote desktop into the new account using the credentials you saved.
Now we need to make this new account register the computer with your jenkins server once it comes online. More details here https://wiki.jenkins.io/display/JENKINS/Distributed+builds#Distributedbuilds-Agenttomasterconnections, and it may be a bit different for you depending on setup, but here’s what we do:
- From the remote desktop of the jenkins user account, open a browser and log into your jenkins server
- Go to the node page for your new machine, and configure the Launch Type to be Launch Agent By Connecting It To The Master
- Switch to the node’s status tab and you should have an orange button to download the agent jnlp file
- Put this file in the %userprofile%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup folder
- Change the Launch Type back to whatever you need (we use the Slave Setup plugin, despite the icky name https://plugins.jenkins.io/slave-setup/) — it doesn’t need to stay as Launch Agent By Connecting It To The Master.
We’re done. log out of remote desktop and reboot the machine. You should see it come alive in the jenkins server after a few minutes. If you remove the -batchmode and -nographics options from your unity commands, you should see the tests start to run with full physics and animation!