After spending days and nights working in the sweat of our brows and making tons of application builds, we finally decided to take a step forward and make some part of our job automatic.
But… why ?
The main reason of making our Continuous Integration system was shortening amount of time spent on building applications. In our last project it lasted even above half an hour, so we decided to make our life easier. We had a list of features we wanted to achieve:
- builds available online to download
- working on multiple unity versions
- building for iOS, Windows and Android on our Windows device
- builds available on our local server
( Our continuous integration system in few simple steps)
About GitLab CI
We chose GitLab CI solution because we had already possessed repositories there. How to configure GitLab and a Runner we described in a separate article:
When we set up our GitLab Runner we had to configure GitLab CI itself by .gitlab-ci.yml
Our system works in two stages : build and deploy. Job named “build” is a template for other jobs. It contains a powershell script which run the unity in batchmode and execute script we wrote in C#.
To do such a thing we need Unity command lines :
| C:\’Program Files’\Unity\Editor\Unity.exe | call unity executable |
| -batchmode | execute in batchmode to prevent the editor from opening |
| -nographics | needed on windows to really make sure there is no GUI |
| -executeMethod BuildScript.Build | calls the Method “Build()” in the Unity BuildScript |
| -projectPath %CI_PROJECT_DIR% | sets the unity project path to default GitLab directory |
| -quit | quit Unity after execution of the build |
+ other variables you want to use in unity e.g. -customProjectName %CI_PROJECT_NAME%
GitLab can hands over some variables such as project name, pipeline id, project direction or build platform target. We use them in our unity internal script to build apps for platforms we have chosen
.build: &build
stage: build
variables:
tags:
- Unity
script:
- C:\"Program Files"\Unity\Hub\Editor\%UNITY_VERSION%\Editor\Unity.exe -projectPath %CI_PROJECT_DIR% -logfile D:\Logs\%BUILD_TARGET%.log -customBuildPath %BUILD_PATH% -customProjectName %CI_PROJECT_NAME% -customBuildTarget %BUILD_TARGET% -pipelineId %CI_PIPELINE_ID% -batchmode -nographics -executeMethod BuildScript.Build -quit
artifacts:
name: "%CI_PROJECT_NAME% %BUILD_TARGET% %CI_PIPELINE_ID%"
paths:
- ./Builds/%CI_PROJECT_NAME%/%CI_PIPELINE_ID%/%BUILD_TARGET%
Builds on demand
We have four options: Windows, Android, iOS and All, we type them in the “run pipeline” section with a “Target” variable. Unfortunately there is no option (for now) to make a list of a variables, so we need to type them manually. If we don’t write anything it automatically run a build for all platforms. This is also a reason why job we named “build” is a template, every platform has their own job and is executed only if we write a correct variable.
Windows:
>>: *build
variables:
BUILD_TARGET: StandaloneWindows64
BUILD_PATH : ./Builds
only:
variables:
- $Target == "Windows"
- $Target == "windows"
- $Target == "All"
- $Target == null
Keep it planned
All builds can be made on demand, but also after every commit in master branch and everyday at 2 AM. Beside that we are able to configure it in GitLabCI/Schedules.
We are also setting a unity version as a variable on the top of our file to be easily configurable at the start of the project.
Where we can find our builds?
We wanted to save builds directly to our local server, but we found out that it was impossible to achieve. We had to workaround it, which we didn’t want to use in the first place – copying from a temporary folder on our disc. We were afraid that it will fill the disc too fast with unnecessary data so we had to also clean the folder after completion. That’s what we are doing in the deploy stage. Builds are also available as the artifacts in GitLab.
As fast as possible
To make the whole process faster we decided to start using unity cache server which helps us to save time at changing between different platforms in unity. When it’s working Unity is downloading converted assets from cache server instead of converting them everytime.
Building iOS apps on Windows
One of our goals was to build everything on one machine and didn’t involve our mac. The major problem was iOS building, because we thought it was impossible to build an .ipa file on Wndows machine, but we have discovered a plugin that helped us fix the problem. Of course it wasn’t one click configurable, we had to transfer all the certificates from our mac etc. Never the less it was worth the pain. We are also able to use it by command lines so it is perfect for our purposes.
Try it yourself
So this is our story of creating continuous integration system with GitLab and Unity. It was harder than it seems to be, but I’m pretty sure that we will keep improving it. The system makes our workflow much more simpler and faster. Don’t wait, go and make yourself your own one!
