RedpointGames
Can I use UET to create Buildgraph of my project for Horde
Hi,
I just set up Horde at our studio. We have been using build targets and build cook run. Horde uses BuildGraph. Was wondering if I Can I use UET to create a Buildgraph XML of our project for Horde build automation.
-Richard
At the most basic level, you could probably grab the BuildGraph XML file we have here and set up the arguments: https://github.com/RedpointGames/uet/blob/main/UET/Redpoint.Uet.BuildPipeline/BuildGraph/BuildGraph_Project.xml
I haven't looked in detail how Horde/BuildGraph is integrated since we don't use Horde at Redpoint, but my understanding is that BuildGraph is used to describe the build jobs in their entirety (in the same way that GitLab has .gitlab-ci.yml).
Because of this, running UET on Horde would require some kind of BuildGraph -> run UET -> import generated BuildGraph XML. From the looks of things, the <Include> element in BuildGraph only supports evaluation immediately, not dynamically on an agent after another set of BuildGraph XML has been generated.
Another approach would be to have a job that runs UET, and has UET stash the BuildGraph XML on shared storage somewhere (like it currently does for dynamically generated macros and includes already). Then have the UET build executor post to the /api/v1/jobs on Horde to create a new build job, where the template is a simple <Include Script="$(ParameterToSharedStorage)" /> and have UET set the ParameterToSharedStorage parameter to the path on shared storage where the rest of the BuildGraph XML is.
Looking at the Horde source code, it seems like there's a mention of "chained jobs" so perhaps we could eliminate UET having to call the /api/v1/jobs endpoint. The problem is that I can't see in the source code how a parent job would pass new arguments down to a chained job (the relevant function seems to be FireJobTriggerAsync), and we would need that to avoid a call to /api/v1/jobs since UET needs some way of informing Horde where it wrote the BuildGraph files.
