Each build runs in a separate custom nat network and the port should not be conflicting due to multiple builds running. Nevertheless, you may modify the source to use custom subnet. The code creating network is here:

https://code.onedev.io/projects/onedev-server/blob/main/server-plugin/server-plugin-executor-docker/src/main/java/io/onedev/server/plugin/docker/DockerExecutor.java?position=source-164.15-164.28-1

You may substitute somewhere in subnet with build number to avoid using same subnet for different builds. For instance, to add below option when creating network:

String subnetOption = "--subnet=172.28." + (jobContext.getBuildNumber()%100) + ".0/24"

Subnet may still overlap for instance when build 2 and build 102 happens to run in the same time. But for experiment purpose, it should be sufficient.

PS: When using custom network, --subnet is equivalent of --bip in default bridge network

You are correct that --subnet is equivalent to --bip. I am not sure what meant the suggestion on stackoverflow.

However, I am pretty sure that the occasional error I am facing is related to running multiple builds at the same time. But why this error happens is all my guess at the moment.

From my own experience with Docker on my NAS, I know that if I run multiple containers in "NAT" mode, ports of each container are being mapped to ports on the Docker host. Benefit is that all containers are accessible at the same IP address from outside, each on a different port. This, sometimes causes problems and port conflicts of apps from different containers want access to the same host port.

Therefore, I prefer running each container in "bridge" mode, so it is visible at a different IP address from outside. This way apps in each container can use whatever ports they want, even the same port number can be exposed on each container. I just have to access them using their own IP address.

So, based on this experience, my guess and suggestion is, that something like that may happen for the 1dev builds running concurrently. Maybe solution would be running them in "bridge" mode.

Sorry I am wrong previously. OneDev build uses bridge network on Linux platform. It only uses bridge on Windows since there are issues creating multiple bridge networks on Windows for docker.

I tried to reproduce this by run multiple builds constantly downloading big files from outside and things work fine. If you can help me reproducing the issue, it will be a lot easier to find out the problem.

It only uses bridge on Windows since there are issues creating multiple bridge networks on Windows for docker.

It only uses NAT on Windows since there are issues creating multiple bridge networks on Windows for docker.

Please check content of /etc/resolve.conf both on host and on created step container. To check content of this file on step container, just add command cat /etc/resolve.conf at very start of the step commands, and then run the build.

Closing this now. Feel free to reopen if you have further info.