Parametrize Multipeer QE tests to run mixed-mode testing

[barkha06]

• Added a build_transport_group function to create a mix of wifi-only, bluetooth- only, and All as transport types for replication to test mixed-mode
• Changed getMultipeerReplicatorStatus response type to be parsed using _assert_string_entry since Android does not return a transport type yet.
• Parametrized document counts and timeouts based on transport type in multipeer tests

[Copilot]

Pull request overview

This PR updates the multipeer QE test suite to support “mixed-mode” transport testing by distributing transport types across devices, adjusting test parameters (doc counts/timeouts) per mode, and relaxing client parsing for multipeer status responses when Android omits transport info.

Changes:

• Add MultipeerTransportType.build_group_transports() to assign per-device transports (including mixed-mode).
• Parametrize QE multipeer tests with transport-specific doc counts/timeouts and pass per-device transports into MultipeerReplicator.
• Update multipeer status response parsing to tolerate missing transport and adjust Jenkins prebuild pipeline behavior.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
tests/QE/test_system_multipeer.py	Parameterizes system multipeer tests and uses per-device transport assignments.
tests/QE/test_multipeer.py	Parameterizes multiple multipeer tests, applies mixed-mode transport assignment, and adjusts timeouts/blobs/docs.
jenkins/pipelines/prebuild/Jenkinsfile	Modifies branch selection logic and changes default build node selection.
client/src/cbltest/response_types.py	Makes multipeer status parsing tolerant of missing transport values.
client/src/cbltest/api/multipeer_replicator_types.py	Adds helper to build transport arrays for uniform or mixed-mode test runs.

Comments suppressed due to low confidence (1)

tests/QE/test_multipeer.py:124

• The retry loop compares results[0].revs against doc.revs, but doc is never refreshed after results is re-fetched inside the loop. This can cause the loop to run until retries are exhausted and then fail (or behave inconsistently) even if the latest fetched docs have converged. Restructure this to re-fetch and compare the current doc for the same device index (or compare all revs in the freshly fetched results set each iteration).

            retry = 5
            while results[0].revs != doc.revs and retry > 0:
                self.mark_test_step("Rev IDs don't match, wait for 30 seconds")
                await asyncio.sleep(30)
                retry = retry - 1
                for mp in multipeer_replicators:
                    status = await mp.wait_for_idle(timeout=timedelta(seconds=timeout))
                    assert all(
                        r.status.replicator_error is None for r in status.replicators
                    ), "Multipeer replicator should not have any errors"
                results = await asyncio.gather(
                    *[
                        db.get_document(DocumentEntry("_default._default", "conflict1"))
                        for db in all_dbs
                    ]
                )
                assert results[0].revs == doc.revs, (
                    f"revision IDs dont match for {doc} even after 5 retries"
                )

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[borrrden]

This creates a makeshift enum out of a magic string for no reason. MultipeerTransportType is already a flag enum, which means it can be bitwise or together (MultipeerTransportType.BLUETOOTH | MultipeerTransportType.WIFI).

Also this seems like a helper method specific to a test suite and not an API method.

[barkha06]

It's a test helper to help generate a mixed mode set with even distribution of wifi only, BT only and wifi+bluetooth devices. I need it for both test_multipeer.py and test_system_multipeer.py so I assumed it could go in the API to make it easy to import.
I've used strings for ease-of-use since the test parameter could of of type MultipeerTransportType or string to represent mixed-mode making it two different types of parameters.
Do you think there's a better way to do this?

[borrrden]

These are flag style enums though so they can represent both anyway like I mentioned above. It doesn't seem like it is the class's job to create collections of itself though, that seems like a higher level thing.

[barkha06]

Where do you recommend I place this function?

[borrrden]

If it were me, I'd start a collection of test helper functions inside of the tests/QE folder.

[borrrden]

As an update, Vipul has now started a shared logic section that you can add this to.