Cloud Mergebots now available for all

We just released Mergebots to Unity DevOps. Previously only available to our on-prem customers, Mergebots are now available to everyone, including cloud users.

Benefits of Mergebots

Mergebots can check for conflicts to further automate your CI pipeline. They do this by checking for conflicts and automatically triggering merges once several qualifying conditions have been met.

Set up requires a few clicks: Define triggers that monitor one or more branches, so that mergebots will scan and find merge conflicts before performing the merge. This process will keep your branches clean and enable easy connectivity with your preferred CI tool.

  • Using mergebots makes merging faster, more transparent, and more secure.

  • Mergebots remove repetitive and manual tasks that may slow down your programmers and artists in their day-to-day tasks.

You can find the mergebots configuration wizard under the 'Settings' button of your repository, in the Unity Dashboard website.


Within this configuration menu, you can automate your merge workflow, enable notifications, and integrate with external CI tools.

Before merging content in your cloud repository, mergebots reduce conflicts by checking if certain conditions are met:

  • Checking if a code review has been created and approved
  • Automatically detecting merge conflicts
  • Automatically re-enqueuing failed merge requests if these were due to new changesets found in the destination branch
  • Checking for individual status parameter attributes and values in order to be triggered and start the merge request automatically (Status, Resolved, Failed, Merge and Testing)


After the content has been merged, mergebots offer handy options:

  • Labeling the merged changeset with your preferred nomenclature (for example: LABEL.${AUTO_INCREMENT_NUMBER}_${BUILD_DATE_FORMATTED, yyyy-MM-dd} will create this label, after each successful merge request handled by mergebots: LABEL.128.2018-10-23)
  • Triggering a build automatically via the integration of popular third-party CI tools such as Jenkins, Team City, and Bamboo


Sample configuration

Once you have configured them, you can trigger mergebots by creating a code review from the Branch menu of your repository, from the Unity DevOps Dashboard.


Finally, once all the conditions are satisfied (Approved Code Review, No merge conflicts, Correct destination branch, etc.), the mergebots will be triggered as soon as you set the Branch attribute to “Resolved” (or whatever value you entered in the configuration wizard).


Once the Merge Request has been finalized, your code review screen should look similar to this screenshot, with 2 color indicators showing its status (pending, failed, or successful).

In the screenshot below, this is an example of how a conflict bot would look like.
It checked whether your merge request created a conflict with the main branch, or if it did not.


Finally, you may see your mergebots current status and configuration in the Settings menu of your repository. You can edit or delete your configuration settings at any time.


Comment with feedback or questions

Let us know if this suits your needs and how we could further improve the mergebot capabilities.


@vitor-unity Hi, we're very excited to get this going. Are there any logs or anything we can use for troubleshooting? I am trying to work out why the merge bots aren't triggering when I expect them to be triggered. Thanks.

@vitor-unity Is there a way to access the source code of these bots? There are some github projects like but they don't seem to be very well maintained. It would be great to have access to the current sources of merge,conflict and multiliner bots and maybe some up to date guide how we setup our own custom bots by adapting the existing ones. Even if this only possible on on-premise servers due to security concerns. The bots are really great but some custom changes are often needed to fully integrate them into dev workflows.

@GMG-Sam I'm sorry, but everything is server side. But, please open a ticket with support using this form: and we will request your org details and what's going on so we can check the logs and determine if there's a problem.

1 Like

Hey @Tracecat , that's right. For security reasons, custom mergebots are not available in the cloud offering. But they are for the on-prem solution.

You have the trunkbot code as well online here:
It's correct both of them haven't been updated in a while, but the core functionality still stands. That being said, feel free to contact me at manuel.lucio at unity3d dot com if you want more details or guidance.

1 Like

Coming from a more traditional CI/CD background, I have the opportunity to discover Plastic SCM during a (very) short work placement in an independent studio.
The studio has modest financial means, the use of an integration server is not feasible, so I decided to try and implement one of the cloud mergebots as they are supposed to work with a cloud repository.

In practice I find that the bot works erratically for similar situations, even in the very simple case like the change of a character in a string in a cs file.

Sometimes the bot merges instantly, sometimes it takes 10 minutes and sometimes its status gets stuck on 'pending' in the branches details dropdown in the dashboard. In this case, editing the bot's config and saving systematically triggers a successful merge.

Here is the bot config :

9175730--1277621--Plastic SCM DevOps Portal.png

The team is working with distributed repositories and i have the feeling that the problem comes from the reposirory attributes that don't sync. There's very little documentation about this : are they it even syncable, it seems so but only when retrieving repository data ? Sometimes there's several ' status ' entries in the Attributes section of the branches details dropdown on the dashboard.

Hi, I'm afraid that the attributes are not syncable on demand. They will be synced only when you also synced some repository data. Please always use the attributed on the central repo (even if you are using a distributed workflow).
After pushing your branch, set the attribute value.

Please let us know if it helps.


Hi, sorry for the late response i had finished my work placement since then. That's what I thought, I would have liked the process to be the simpliest possible, so no switching between local and centralized repo. But that'll do I guess !
Thanks again for taking the time to give me an input .

Is it possible to use the mergebot to automatically trigger a Jenkins-build, whenever a Branch is merged to another branch that is validated by a RegEx Expression or similar?
Merging from feature-1-dev to feature-1-prod should trigger the build "Build-feature-1" on jenkins
Merging from feature-2-dev to feature-2-prod should trigger the build "Build-feature-2" on jenkins

Currently, I can only see the option to set up the mergebot with one Destination branch, but I would need all *-prod Branches as Destinationen. Setting them all up individually is not an option.

The mergebot is a trunkbot. It means it was designed for a workflow where you have task branches and you want to integrate them to the main/trunk branch. You cannot define multiple destinations.

In your case, how would you link each source branch with each destination branch? Only with the number?
feature--dev -> feature--prod

Although you may have dozens of candidate target branches, the bot needs to know which "source" branches have to go to which "target" branches. What criteria do you expect to be met to relate the two?

Are the feature--dev branches child branches created from feature--prod?

I link all the branches via name and yes, they are also child branches of the production branches like so:
So the criteria I would use is the direct child branch relation and I would like to trigger it when the parent-branch has a specific name like *-stage or *-prod

I am trying to figure out a way to create a multibranch pipeline in Jenkins or similar as already stated in this forum post:

Would it be ok for you if we ignore the "specific name" part of your request but if you don't want to integrate a specific task branch into the parent one, it will be enough without setting any attribute for that purpose.

I am not 100% sure I can correctly understand your Message but if you are saying if it is a possibility that I can not use the "specific name" but only the direct child-parent relation as a trigger. Yes that would at least help and I might be able to get around the naming on my own.

Let me share this with the dev team. I think it's a good to have but not sure if it can be planned in the near future.