rerun_of parameter should accept launch id instead of uuid

[rplevka]

Currently, the rerun_of parameter accepts UUID of the parent launch. This is tricky to use for multiple reruns, as creating a new rerun launch immediately changes the UUID of the target launch. We have to locate the same launch again and find its updated UUID if we want to re-run it again.

It would make much more sense if the parameter used the id of the launch, which does not change. Switching to launch id would also potentially fix https://github.com/reportportal/reportportal/issues/1527

[HardNorth]

@rplevka If I rerun a Launch with rerun_of I get the same ID in the response, see screenshot:

[HardNorth]

@rplevka Got it. The start_time should also be the same to get the same UUID.

[HardNorth]

@rplevka Ahh, got it! Launch URL should be /api/v1/default_personal/launch, but Python client usually use /api/v2/default_personal/launch Hmm. Maybe we need to switch back on v1, considering how popular multi-processing in Python.

[rplevka]

@HardNorth thanks for looking into this. Are you saying that the non-async (v1) endpoint works correctly with this? I'm actually using my own client to parse pytest junit xml file and push the results to RP, so i'm probably fine with v1 endpoint.

Howver, my plan is to run multiple reruns of a launch at the same time - different test collections though. There I might hit some concurrency issues

[HardNorth]

@rplevka Not really, I believe it's by design. Just a matter of how it's used.

[DzmitryHumianiuk]

We definitely should rework the way re-run works right now.

@rplevka closing for now. plz lemme know if thread is still actual

[rplevka]

@DzmitryHumianiuk I believe the request is still valid and implementing it would make reruns/retries usage much more user friendly and the api usage more consistent

[DzmitryHumianiuk]

@rplevka agree. we need to look at blueprints of re-run again.