C7-Game / Prototype

An early-stage, open-source 4X strategy game
https://c7-game.github.io/
MIT License
34 stars 9 forks source link

Export C7 Game Should Fail if Project Fails to Build #306

Open QuintillusCFC opened 2 years ago

QuintillusCFC commented 2 years ago

See https://github.com/C7-Game/Prototype/runs/7297094073?check_suite_focus=true, open the Windows Build section (or Linux, or probably Mac), expand the logs, and you'll see:

ERROR: Failed to export project: Failed to build project
   at: godot_icall_GD_pusherror (modules/mono/glue/gd_glue.cpp:249)

This is a real failure, but the build succeeds. It should fail.

To reproduce this, you can set your .NET version so something that the build server doesn't support. Right now it supports net472 but not net6.0, but if it later supports that, try setting it to something like net9.7 to cause this error again.

QuintillusCFC commented 1 year ago

Confirmed that Godot sets an error code of 1 if it fails to succeed; you can check this on Windows by running echo %errorlevel% after running godot.exe -v --export "Windows Desktop" OutputFolder/C7.exe; if it succeeds, it sets it to 0.

It looks like echo $? does the same thing in Bash, which is probably what our build server is running, so in theory we should be able to check $? to see whether we succeeded, and if not then we just have to figure out how to fail. We have some code that sort of looks like that for the file-copying step, but I'm not sure if that actually causes a failure either, or just prints out a scary warning in the logs.

Gonna self-assign this and move it to in-progress, it looks solveable with some sleep and a few tests of it running in its native environment.

QuintillusCFC commented 1 year ago

Also adding to Carthage, as #308 already is in Carthage and while it might not technically require this, it's a whole lot more useful if this one is done first and it isn't just saying it succeeded all the time whether it actually did or not.

QuintillusCFC commented 1 year ago

I'm giving up on this. I created two branches to try to fix this:

https://github.com/C7-Game/Prototype/tree/306-Failing-to-Fail https://github.com/C7-Game/Prototype/tree/306-II-Failing-to-Fail

But in neither case could I get it to consistently fail when it should fail, and succeed when it should succeed. E.g. workflow https://github.com/C7-Game/Prototype/actions/runs/3062333231 uses the latest commit on 306-II-Failing-to-Fail, and even though the logs say the build failed, the return value still winds up being 0.

Testing manually on Ubuntu, the return value is 1 when it fails, which matches what I see on Windows. So it's something weird about the build server I guess. Or maybe bash (is the build server not really running bash maybe?). Either way it's too tedious to test and check and my Linux/Bash expertise is not high enough to resolve it. I'm much better at coding things than bash scripts/infrastructure things, thought this would be quick but it clearly isn't.

WildWeazel commented 1 year ago

I'll look into it.

QuintillusCFC commented 1 year ago

Thanks!