Updates on Unreal Engine Support in TeamCity: UGS Integration and Open-Sourcing the Plugin

We’ve got a few exciting updates about the Unreal Engine plugin announced in the previous blog post.

TL;DR – we’re adding Unreal Game Sync (UGS) integration and open-sourcing the plugin. These updates are all about making the CI/CD experience smoother for Unreal Engine devs and getting the community more involved.

UGS

Before diving in, let’s quickly go over what Unreal Game Sync (UGS) is for anyone who might not be familiar with it or could use a refresher. In essence, UGS is a lightweight UI for Perforce. Typically, you need to build it from source to get started, and while its graphical client is a WinForms application available only on Windows, there is a command-line interface (CLI) version for other platforms. UGS has been around for a while and is widely used by game studios working with Unreal Engine as a collaboration tool.

From a CI/CD perspective, UGS provides valuable insights into a project’s status (if properly set up), such as build statuses, the ability to flag specific changelists as problematic, and more. To give a better overview, here’s a rough diagram of the components involved:

There are quite a few components here, with the central one being the Metadata Server. While deploying it isn’t strictly necessary, it does enable the full feature set of UGS. This is also where CI/CD systems post build information. As shown, there are different possible implementations of the Metadata Server, and it’s worth briefly discussing each:

• Epic Metadata Service. This is the original and longest-standing version of the Metadata Server. It requires Windows, IIS, and the older .NET Framework 4.6.2.
• Third-party implementation. Thanks to the open-source nature of the server, it’s possible to create your own implementation. One example is RUGS, which is much easier to set up since it supports Docker.
• Horde. Technically, this is a full-fledged automation platform recently introduced by Epic. It includes a built-in UGS Metadata Server as well as its own build system. Although it has a built-in metadata server, it doesn’t allow publishing from external sources – the transition to Horde assumes that all metadata is generated internally. Horde is a bit outside the scope of this blog post, so we’re only mentioning it for the sake of completeness.

Entities that the build system is supposed to post to the metadata server are called “badges” in UGS terms. These badges will then show up in the CIS (continuous integration status) column in UGS. It usually looks like this:

As far as we know, the metadata server endpoints don’t currently have authentication. It appears that the server is intended to be used within a secure, closed network, but this is just our understanding and not an official statement.

For a more complete definition of UGS please refer to the official documentation.

UGS Integration in TeamCity

Let’s take a look at UGS integration in TeamCity. As of the most recent plugin update, we support these two scenarios:

1. Publishing a badge as a build status via the Commit Status Publisher.
2. Publishing an arbitrary set of badges defined in your BuildGraph script.
   This applies to the “distributed” execution mode – a special runner mode in which the BuildGraph definition of the build is converted into a set of builds in TeamCity (build chain). For more details, please refer to our previous blog post or the plugin documentation.

The first scenario is pretty straightforward. You only need to configure the Commit Status Publisher build feature and set up a few required parameters.

The second scenario is more complex. In your script, you can define a set of badges and link them to specific nodes to be tracked. Before diving into the scripts, here’s a quick reminder of how the plugin maps BuildGraph entities to TeamCity entities:

For example, if your build process includes compiling an editor, the script might look like this (with unimportant details omitted):

<Agent Name="Build Editor and tools" Type="...">
    <Node Name="Set binary version">
        ...
    </Node>

    <Node Name="Compile Tools" Requires="Set binary version">
        ...
    </Node>

    <Node Name="Compile Editor" Requires="Compile Tools">
        ...
    </Node>
</Agent>

<Badge Name="Compile Editor" Project="//UE5/Main/Samples/Games/Lyra" Requires="Compile Editor"/>

Here, we define a badge named “Compile Editor” to track the execution of a node with the same name. In distributed BuildGraph mode, TeamCity will recognize this badge and update the build status as the process progresses.

You can define multiple badges to track different sets of nodes, and TeamCity will monitor all of them based on the specified dependencies:

<Agent Name="Build A" Type="A">
    <Node Name="Node 1">
        ...
    </Node>
</Agent>

<Agent Name="Build B" Type="B">
    <Node Name="Node 2">
        ...
    </Node>
</Agent>

<Agent Name="Build C" Type="C">
    <Node Name="Node 3">
        ...
    </Node>
</Agent>

<Badge Name="BuildProject" Project="//foo/bar/project" Requires="Node A;Node B;Node C"/>

In this example, there are three agents (each with a single node) that can potentially run concurrently, as they are assigned to different agents and have no dependencies on each other. Each build is tracked by a corresponding badge.

The badge will behave as follows:

• “Starting” – displayed as soon as any tracked dependency begins execution.
• “Success” – shown when all dependencies complete successfully.
• “Failure” – Indicated if any dependency encounters an error.

For complete examples, please refer to the plugin’s user guide on GitHub.

Open-sourcing the Plugin

We have received a lot of feedback since the plugin was introduced in May this year. Thank you to everyone who shared ideas for further development, submitted feature requests, or reported bugs! We’ve also been asked several times whether we’re going to open-source the plugin and, if so, when. That time is now!

With this step, we hope to:

• Increase transparency and trust in the plugin’s codebase.
• Engage the community for contributions and improvements.
• Speed up bug fixes and feature implementations.

The source code is now available on GitHub and the latest release is ready for download on the marketplace. We encourage you to submit feature requests, report any bugs you encounter, suggest enhancements, or fork the plugin and customize it to fit your needs.

Cheers!