Detect running server on startup

[GauravKumar9920]

🦟 Bug fix and New feature

Fixes #2806

Summary

Previously, when launching multiple GZ Sim servers, for instance, using the commands gz sim -s shapes.sdf and gz sim -s default.sdf,

If we had used the command gz sim -g ‘fileName’,
It would not have considered the fileName parameter and would have launched any of the servers at random.

This pr introduces a new feature that allows you to -

• Launch a file by passing the file name as an argument. For instance, you can utilize the command gz sim -g ‘fileName’ to launch the GUI, provided that the server(s) are operational.
• Warn the user if there are multiple servers running in case where we don't pass the fileName as an argument. eg - gz sim -g. In case there's just one server running it will simply launch the gui of the same.

[arjo129]

This diff is absolutely massive for such a small change. I've left some architectural feedback here: #2806 (comment)

Also when committing please sign off with git commit -s.

I think we can break these down into small PRs.

[iche033]

I think the big diff is also partly due to indentation changes, e.g. https://github.com/gazebosim/gz-sim/pull/2828/files?w=1 shows diff without whitespace changes. Can you undo indentation changes?

[codecov]

Codecov Report

Attention: Patch coverage is 83.33333% with 2 lines in your changes missing coverage. Please review.

Project coverage is 68.97%. Comparing base (1509b0f) to head (b848079).
Report is 9 commits behind head on gz-sim9.

Files with missing lines	Patch %	Lines
src/SimulationRunner.cc	80.00%	1 Missing ⚠️
src/gui/QuickStartHandler.cc	85.71%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           gz-sim9    #2828      +/-   ##
===========================================
+ Coverage    68.95%   68.97%   +0.02%     
===========================================
  Files          345      345              
  Lines        33332    33360      +28     
===========================================
+ Hits         22983    23009      +26     
- Misses       10349    10351       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[arjo129]

This is looking a lot better. Most of my comments are more to do with syntax and style. I have one tiny knit regarding returning an incompletely constructed object. For now we should just continue with construction as is. In Jetty we can consider throwing an error.

[arjo129]

LGTM! Thanks for iterating.

[iche033]

looks good to me, just minor suggestions

[GauravKumar9920]

Hello, apologies for the slow response on this thread was a bit occupied for the last few weeks.
I went ahead and tested the current code, and it seems to be working as expected. However, I’m still encountering some issues with the GitHub Actions errors. Can you help me out with that?

[iche033]

Hello, apologies for the slow response on this thread was a bit occupied for the last few weeks. I went ahead and tested the current code, and it seems to be working as expected. However, I’m still encountering some issues with the GitHub Actions errors. Can you help me out with that?

The UNIT_Gui_TEST is failing because I think the changes affected how fast the QuickStart window comes up. Can you try applying this diff and see if that fixes the test on our CI?

diff --git a/src/gui/Gui_TEST.cc b/src/gui/Gui_TEST.cc
index ce5b42576..6f4c1d92a 100644
--- a/src/gui/Gui_TEST.cc
+++ b/src/gui/Gui_TEST.cc
@@ -252,6 +252,9 @@ TEST_F(GuiTest, GZ_UTILS_TEST_ENABLED_ONLY_ON_LINUX(QuickStart))
     // Close the quick start window
     gzdbg << "Closing the quickstart window" << std::endl;
     ASSERT_EQ(1, gui::App()->allWindows().count());
+
+    while (!gui::App()->allWindows()[0]->isExposed())
+      std::this_thread::sleep_for(std::chrono::milliseconds(100));
     gui::App()->allWindows()[0]->close();
 
     gzdbg << "Waiting for main window" << std::endl;

[GauravKumar9920]

Hello @iche033, Makes sense and I have made the changes, and it appears to build successfully except for one of them.

[iche033]

ok I've seen the homebrew failures before. Those just started recently and I don't believe this PR caused those failures.

[arjo129]

Thanks for this contribution!