I want to run the ResavePackages UAT command on my whole project but because it’s a process that will run over several hours, I don’t want it to stop if there is an error, like a missing property in a blueprint or something. Every time an error occurs, the whole command ends, the errors logged, and the changelist with all the resaved packages is reverted. Is there a built-in way to let the command ignore errors or will I need to make such a change?
For context, I’m referring to the AutomationScripts.Automation.ResavePackages build command executed using RunUAT.bat. I have my own version of that command that I’ve made some modifications to. I’m thinking that as a last resort I can just stop it from ever reverting the changelist, but I want to know if there is way to prevent the ResavePackages commandlet from raising package loading errors in the first place. If a package has an error, just want it logged and ignored without impacting the commandlet’s exit code. Is this possible?
I actually already created a new build command based on AutomationScripts.Automation.ResavePackages that more tailors to my team’s needs. I haven’t changed any of the error handling yet so I wanted to check here to make sure I didn’t miss anything.
My main goal with this question was to determine whether there was any way of handling the errors more gracefully. It sounds like that’s not the case here so I’ll go to my fallback plan of preventing my custom command from reverting the changelist, even on errors. Since we’ll be cooking content before and after resaving to make sure that new errors aren’t introduced by the resave, we’ll have an opportunity to catch any data corruption before the resaved content is submitted.
I’m assuming that the failure of the commandlet is related to the log containing Errors. One way to work around the problem is to change the verbosity of the log channel but that would suppress the messages so it’s not ideal. We usually fail the entire operations on Errors since it is not always easy to know if the error is related with the current operation. In the case of the ResavePackage commandlet, the editor could have crashes while saving a file which might result in corrupted data.
AutomationScripts.Automation.ResavePackages is quite old and only in maintenance mode at this point. It is mostly a wrapper around a call to the Editor and to deal with the results. You can extract the editor command from the log and build a new script around it. I think this would be safer than suppressing messages.
The Resave Package doesn’t do much other than loading and saving the assets. It should not be necessary to validate the operation when it completes successfully. It’s the same code paths than when any user is manipulating the assets in the editor.