In my Node.js server, I have set up a route for POST actions to go to called ‘builds’.

Let’s look at an example of configuring a webhook that will send a POST request to an API endpoint I manage/own when a build of my Unity project successfully completes.įor this I will be running a simple Node.js express web server with body-parser middleware. You can choose a particular content type that the webhook payload is delivered with (one that your API would understand like application/json). For example, on the successful completion of a build. The question then is, how do you continue this automation pipeline after Unity Cloud has finished your build?Ī webhook is an HTTP POST request that Unity Cloud Build can send to an API endpoint you specify, whenever a particular event in your build pipeline occurs. You can even configure it to watch a specific branch and create builds from that branch, effectively allowing you to branch off of the trunk/master and work in feature branches, then merge work back into ‘release’ branches.

This is great, and allows you to automate builds for various platforms – PC, Mac, Mobile, etc all by just updating your source repository. Unity Cloud Build already allows you to hook up to your Git (or other) repository to the Cloud Builds platform, and have automated builds created of your project whenever you push code up to your repository. Unity Cloud Build helps solve some of this, but there is more that can be done… If you add up the time spent copying build releases, updating websites with new build information, sending out notifications or change logs, etc… that time can really add up in the long run. Once you’ve figured out a general process for deploying game releases, you certainly don’t want to be manually completing every step of the process every time there is a release.

Unity cloud build long build time