Tips and trips for setting up Continuous Integration (CI) for your projects
Continuous Integration means that any changes to the project are merged frequently into the main branch, and automation (especially of testing) is used to ensure quality. The main benefits of Continuous Integration (henceforth CI) are that it makes software development easier, faster, and less risky for developers. Building your Game Client with CI and automated testing might require coherence setup.
For automated delivery of your project changes and testing it in CI, you can take the following steps to make sure coherence is set up appropriately in your project before building a standalone Client.
Make sure you generate your schema or schemas before building. For example, you can create a build method and call it from Unity via command line as a custom method.
After that, you will need to bake your code according to the schema. Baking is also accessible via the Unity command line in a custom method.
To start the Replication Server in CI you can also use scripts generated in ./Library/coherence folder /project_path/Library/coherence/run-replication-server-rooms.sh and /project_path/Library/coherence/run-replication-server-worlds.sh.
If you want to automate the uploading of schemas, keep in mind that you need to set the COHERENCE_PORTAL_TOKEN environment variable in your continuous integration setup so the upload is accepted by the coherence Cloud. You can get the token from coherence Dashboard > Project > Settings > Project Settings > Project Token.
You can use the Simulator Build Pipeline public API to build and upload your Simulator builds to the coherence Cloud from the command line. If you wish to learn more about Simulators, check out the dedicated section.
There are two methods you will need to call, in order, to build and upload a Simulator build successfully:
Coherence.Build.SimulatorBuildPipeline.PrepareHeadlessBuild This method will add the COHERENCE_SIMULATOR scripting symbol, will set the build sub target to Server (for Unity 2021) and it will change the platform to Linux. It is necessary to perform these steps in an isolated Unity execution, because in batch mode, there is no editor loop that will make sure your assemblies are reloaded with the changes.
Coherence.Build.SimulatorBuildPipeline.BuildHeadlessLinuxClientAsync ****This method will build the Unity Client and upload it to your selected organization and project.
In order to be able to interact with your coherence Dashboard from the command line, you will need to export your project token as an environment variable.
You can create your custom build steps by implementing Unity interfaces IPreprocessBuildWithReport and IPostprocessBuildWithReport. In order to verify that the build being created is a Simulator, you can check for the SimulatorBuildPipeline.IsBuildingSimulator boolean.
If you're using a VCS (which we highly recommend you to) like git, Subversion or PlasticSCM, here's a few tips.
You can ignore (as in, not version) Assets/coherence/baked and its .meta file in most cases, but it's completely safe to include them too. If you decide to ignore them, every other fresh copy of the project (including continuous integration setups) has to Bake for such files to be generated.
If your build pipeline relies on asset checksums for verification, you should version the forementioned files.
Make sure Assets/coherence/Gathered.schema is treated as a binary and not as a text file (where conflicts can be auto-resolved via content diffs). The Gathered.schema, although a text file, is meant to be thought of as a binary file.
Each VCS has different mechanisms to work around this. Read the documentation of your VCS of choice to learn how to set this up.
When using git, you can add this line to your .gitattributes file (or create one in the root of your repo, if it doesn't exist)
To learn more about how gitattributes works, refer to their documentation.