Hi,
We’re trying to extend our Horde based build process to add automated storefront deployments. We are also utilizing OnlineSubsystems with custom config so we have separate targets for different storefront that derive from our GameTarget and set the CustomConfig value.
I would like to ask three questions:
- What’s the recommended approach for using the deployment to storefront task(eg. Lyra’s DeployToEpicGameStore) in Horde?
- Is it possible to somehow implement multiple target support into BuildAndTestProject.xml to not rerun all steps just for a custom config change?
- Is it possible to set Horde to trigger a template based on another template result? (eg. If BuildAndTestProject has finished for normal GameTarget then using that data build other storefronts and upload the files)
Kindest regards,
Mateusz
Hi Mateusz,
Thanks for your question - it’s an interesting one!
- Admittedly we do not do this internally, and as a result, don’t exactly have a great recommendation. DeployToEpicGameStore does seem like a suitable starting point.
- I’m not following your question here. Are you referring to a build graph target, or a UBT Target?
- Whilst chainedJobs exists, it too isn’t used internally. We instead defer to a custom Build Graph task that we have authored to kick off a separate job. A similar question has come up before, which may also be [helpful in highlighting some [Content removed]
- I’ve made an internal user request to see if we can make our custom build graph task more publicly available, as this isn’t exactly an uncommon ask.
Kind regards,
Julian
Hi Mateusz,
- > Is it possible to somehow implement multiple target support into BuildAndTestProject.xml to not rerun all steps just for a custom config change?
- >I’m referring to a UBT target. Right now we have a similar situation like in Lyra where we have different targets derived from our GameTarget(Target code below)
So what are we trying to achieve here then? This is extremely common - given the UBTarget context, I’m not sure I follow the “not rerun all steps for a custom config change”. When issuing a build graph command, you can target specific nodes to make sure you’re only building your game target.
Julian
Hey Mateusz,
Hmm, good question. It sort of depends - my hunch says probably not avoidable, but it depends what the two different “config” means. If it’s actually separate (build) configs, then I don’t think there’s much value trying to share certain prebuilt aspects, as this could be risky and introduce all kinds of portability/wonkiness.
If the “configs” just produce some separate ancillary files, you could try and break this out as a single task, andTag the files to be shared in the two subsequent storefront “jobs”.
Julian
Hi Mateusz,
Thanks for this. Just quickly reading the code, CUSTOM_CONFIG (and CustomConfig) is annotated with RequiresUniqueBuildEnvironment, which means it will fundamentally impact the compile arguments (which checks out with how the data is consumed within the build pipeline). I don’t think it’d be wise to try and reuse intermediates (which is fundamentally what we’d be doin to avoid having to compile twice). Since this does appear to be used in the final data packaging, I’d probably try to relegate the separate config to a weekly (unless you’re attempting to test it on a regular basis). At least with this approach, you’d remove any potential undefined behaviour by reusing intermediates, and also reduce the breadth of builds.
I hope that clarifies the approach.
Kind regards,
Julian
Hi Julian,
Thanks for fast response.
- Alright I’m just gonna try to apply DeployToEpicGameStore into a custom version of BuildAndTestProject.xml but ideally it would be better to separate the BuildCookRun and storefront deployments.
- I’m referring to a UBT target. Right now we have a similar situation like in Lyra where we have different targets derived from our GameTarget(Target code below)
- Thanks for the request the task would be really helpful. As for the link to a similar question it doesn’t seem to open for me.
Target code:
`public class MyGameTarget : TargetRules
{
public RoadDinerTarget(TargetInfo Target) : base(Target)
{
Type = TargetType.Game;
DefaultBuildSettings = BuildSettingsVersion.V5;
IncludeOrderVersion = EngineIncludeOrderVersion.Unreal5_5;
ExtraModuleNames.Add(“MyGame”);
}
}
public class MyGameEGSTarget : MyGameTarget
{
public MyGameEGSTarget(TargetInfo Target) : base(Target)
{
CustomConfig = “EGS”;
}
}` Kind regards,
Mateusz
Hi Julian,
Yeah sorry I think I phrased my question wrong. Right now I potentially need to do 2 builds for the different config on a Windows platform for 2 storefronts. Can this somehow be avoided?
Mateusz
Hi Julian,
So far for us different config for other storefronts means just different value of CustomConfig variable in the build target.
Mateusz
Hi Julian,
Thanks for clarification. That’s exactly what I needed.
Kind regards,
Mateusz