Improve output on gradle check timeout

[andrross]

The result ends up being reported as 'null' when this script times out. Also the output never directly indicates that a timeout occurred, so this commit makes the output more explicit.

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[codecov-commenter]

Codecov Report

Merging #2913 (4b4c8ab) into main (565735b) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #2913   +/-   ##
=======================================
  Coverage   93.00%   93.00%           
=======================================
  Files         165      165           
  Lines        4518     4518           
=======================================
  Hits         4202     4202           
  Misses        316      316           

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[peterzhuamazon]

The issue with this approach is, it is possible that we have running state = false, while seconds exceeds timeout value.

You would end up with a success test, but still failed due to timeout, as seconds will continue to count.

running=false
seconds=7200+
timeout=7200
results=success
return=timeout

My initial approach is to accurately compute the number of timepass, so I can control when to add up the time instead of letting it compute by itself.

I think we can definitely improve the output, but no need to change the structure of the time calculation.

Thanks.

[andrross]

I think we can definitely improve the output, but no need to change the structure of the time calculation.

@peterzhuamazon Good call out. I'm happy to change this back to the way it was, but let me know what you think of the updated approach I just published. It should fix the issue you mentioned. The reason I changed the time calculation is so that the script will print the accurate elapsed time instead of always being 30 seconds ahead.

[peterzhuamazon]

I think we can definitely improve the output, but no need to change the structure of the time calculation.

@peterzhuamazon Good call out. I'm happy to change this back to the way it was, but let me know what you think of the updated approach I just published. It should fix the issue you mentioned. The reason I changed the time calculation is so that the script will print the accurate elapsed time instead of always being 30 seconds ahead.

I think this still needs some testing, as there are cases where timeout reached but then running state changed to false right after, still not safe.

I dont think the 30seconds ahead count is really a big issue tho.
Let's just merge the results changes without touching the time calculation for now.

Thanks,
Peter