the adapter. The limit can be set in the configuration file, for example: max_run_time: 12765h. https://docs.rs/duration-str/0.11.2/duration_str/ shows the supported formats. The default is one hour.

In addition to limiting the run time, this patch changes how the adapter’s stdout and stderr output is captured. This should make the CI broker not get stuck if the adapter produces a lot of output to either stream.

Additionally, there is a limit to how much output the CI broker accepts from the adapter. If there is more output, the adapter process is terminated with extreme prejudice, and the CI run fails. The limit is not currently configurable, and is hard coded to 10 MiB. I can make this, too, configurable, if someone explains why they need it to be configurable.

All the interesting code is in the new module src/timeoutcmd.rs. That is some quite intricate code. It’s intricate, because it’s doing several things concurrently: spawning a sub-process, feeding it input via stdin, capture anything it writes to stdout or stderr, terminating the sub-process if it runs for too long, or produces too much output, or the main thread requests. Further, the output capturing is done in a way that allows the main thread to process the output in real time: this is needed for the CI broker to react to the adapter’s messages as they are received, without waiting until the adapter process ends. The module also does this without getting stuck or crashing, in any of the scenarios I have been able to come up with. The end of the timeoutcmd.rs module has a bunch of tests to verify the code works in those scenarios to make sure the module keeps working.