Currently, the Mutation Server Protocol (MSP) reports the selected port via STDOUT, but there’s no mention in the protocol specification about using a user-configurable port. This works fine in local development but becomes challenging in containerized environments.
For example, in the Stryker Cloud Orchestrator setup, which distributes the mutation testing process across multiple workers, the tool implementing MSP will run in a separate container. Which makes it hard to retrieve the port from STDOUT.
In my use case, I want to control the mutation testing tool via MSP from a separate worker container. Without a way to set a fixed port, it’s challenging to establish reliable communication between the worker and the MSP server since the port may change dynamically.
The mutation server may use a user-configurable port specified through a command-line option or configuration setting.
This small addition to the documentation would clarify that implementations can support a user-defined port, making it clear for users and tool developers that this option is available when needed.
I agree with the proposed addition to the documentation, good idea! Allowing a user-configurable port would provide the flexibility needed for containerized environments.
Currently, the Mutation Server Protocol (MSP) reports the selected port via STDOUT, but there’s no mention in the protocol specification about using a user-configurable port. This works fine in local development but becomes challenging in containerized environments.
For example, in the Stryker Cloud Orchestrator setup, which distributes the mutation testing process across multiple workers, the tool implementing MSP will run in a separate container. Which makes it hard to retrieve the port from STDOUT.
In my use case, I want to control the mutation testing tool via MSP from a separate worker container. Without a way to set a fixed port, it’s challenging to establish reliable communication between the worker and the MSP server since the port may change dynamically.
Proposed Update
I suggest extending the base protocol documentation with the following note:
This small addition to the documentation would clarify that implementations can support a user-defined port, making it clear for users and tool developers that this option is available when needed.