Add --notgame arg that omits -game flag in runAutomationCommands
Problem
The automatic inclusion of the -game when calling the editor binary prevents use of ue4cli test with editor plugins.
Proposed solution
Include -game by default but enable its omission with a --notgame flag. Potentially Resolves #22
Notes
- Explored multiple argument signatures
-
--enableeditorWas misleading because it implies that the "UnrealEditor" is disabled. -
--editorpluginWas misleading because other arguments would likely need to be used in conjunction with this argument for editor plugins -
--notgameSeemed to be the most concise (please subject to scrutiny)
-
- Attempted to mimmic code-style.
@PaulHax test with
git clone https://github.com/dskvr/ue4cli && cd ue4cli
git checkout feature/editor-plugin-support
#check your python version is 3.x
python --version
python setup.py install
cd path/to/plugin/source
ue4 test --notgame EditorPluginName
Yes! This does it for me:
ue4 test --notgame MyEditorModuleTest
One slightly sad thing for another day perhaps:
ue4 test --notgame --list <- does not list MyEditorModuleTest because UnrealManagerBase::listAutomationTests() does not call UnrealManagerBase::runAutomationCommands(..., disableGameArg=True)
@PaulHax At first glance that appears to be because UnrealManagerBase::listAutomationTests() looks for .uproject files and not .uplugin files.
@adamrehn Is there any chance of this making it into ue4cli?
Apologies for the delay in responding to this pull request, I've been inordinately busy over the past couple of months and I'm only now making my way through my GitHub backlog.
Please see my comment https://github.com/adamrehn/ue4cli/issues/22#issuecomment-678984973 for details of why I've avoided providing an option to disable passing the -game flag to the Unreal Editor when running automation tests. I'll revisit this pull request once I've found a solution that is able to robustly run automation tests both with and without the -game flag across multiple platforms and versions of the Unreal Engine.
@adamrehn Thanks for the response, we'll likely maintain our own fork during the interim as the modification is behaving as expected in our limited use case.