Horde Preflight Recommendations

Development Pipeline & Plugins
, ,
1

Hello!

We are currently working on deploying preflight to our studio as a whole. To optimize for compute usage we are thinking of having many different types of Preflights. Currently the thought is we will have 4 different kinds of preflights, these would all be inserted as definitions in the SubmitTool

  1. Code Only - If only CPP and Header files change we just build Linux Server and Windows Client and call it good
    1. We build the Editor when we make PCBs for our developers. This happens each time a Developer commits code, building editor here seems like a waste of compute but maybe we should
    2. This wont catch things like removing UFUNCTION on a blueprint callable function. I was thinking of doing a blueprint compile as part of this step but this is way too slow on our project
  2. Content Only - IncrementalCook of Window Client.
  3. Code + Content - Build & Cook - Incremental Cook + Build of Changelist
  4. Code + Content + Stage - Incremental Cook + Build of Changelist (Client & Server) as well as staging and archiving the preflight artifacts

Each of these gets progressively more expensive compute wise. Is this a good approach to optimize our preflights to do the necessary amount of work required to validate a change. Another approach would be to always #3 or #4 and do the full process for every preflight, but this seems overkill. Would be good to have some insights on what you guys do on your projects.

2

Steps to Reproduce

3

Hello,

This is highly dependent on your tolerance to warnings, errors, risks and costs. Epic has a “warning as errors” internal policy so we invest a lot in preflights. We have pretty much the same configuration that you shared and it’s up to the contributors to run what is appropriate for the change they are about to commit. We still have automated job that will incrementally compile and cook the streams on a regular bases since it’s impossible to catch everything with preflights. One difference we have is that we normally include the editor in our preflights to avoid breaking jobs that depend on it. The jobs are configurable so it’s up to the submitter to be diligent in choosing what to validate against.

Regarding content changes, cooking can always be done locally (vs the farm) or it’s possible to cook single packages\maps but that might be pretty much the case with incremental cook.

Costs are where things get challenging as you must balance the operation costs with the impact on production which are very difficult to measure. One thing that can help is doing incremental code builds as much as possible but it might already be the case for your jobs.

I hope this will be useful! Maybe other licensees will be able to chip in and comment on what they do internally.

Regards,

Martin