Fix for issue#687

[Ravisaketi]

Proposed changes

Call to the QL's version endpoint #687

Types of changes

What types of changes does your code introduce to the project?
Put an x in the boxes that apply

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Maintenance (update of libraries or other dependences)

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

• I have read the CONTRIBUTING doc
• I have signed the CLA
• I have added tests that prove my fix is effective or that my feature works
• I have run all the existing tests locally (not just those related to my feature) and there are no errors
• After the last push to the PR branch, I have run the lint script locally and there are no changes to the code base
• I have updated the RELEASE NOTES
• I have added necessary documentation (if appropriate)
• Any dependent changes have been merged and published in downstream modules

Further comments

If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc...

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️

[c0c0n3]

@Necravisaketi I've sketched out an improved flow. If you agree, after implementing it, please run the benchmark to make sure everything is hunky-dory---those tests aren't part of our automated test suite, so you'll have to run them manually.

[c0c0n3]

That's a good start, but there's still room for improvement :-)

The problem with this approach is that if QL starts after the requests.get call, the benchmark will exit. Ideally we should wait until we know QL is up or bail out after a max amount of secs. There's a function in reporter.tests.utils we can use to implement this flow. I'm sketching out how below in pseudo code.

from reporter.tests.utils import wait_until

def _can_get_ql_version() -> bool:
    status = requests.get(version_url)
    return status == okay

def wait_for_ql():
    wait_until(_can_get_ql_version)

class TestScript:
    ...
    def _start_docker_and_wait_for_services(self):
        self._docker.start()
        wait_for_ql()
        # If QL is up, then Redis & DB backend are up to b/c of docker deps.