The reason not providing agent docker image is that agent package is generated from current version of server, and always get upgraded automatically when server is upgraded. If maintain an agent docker image, I have to maintain a server/agent version compatibility matrix which adds overhead.

Also for large scale CI/CD jobs, OneDev can run them as pods in k8s without agents.

Hm I see. But I think it would be totally fine to not have a compatibility matrix and instead define that server and agent must have the same version. People usually use some tools to deploy docker swarm services, e.g. docker compose. I would be totally fine to update the version of the 1dev/server image as well as the version of 1dev/agent image in that docker-compose.yml file so that they always match.

My workflow would be:

1. Scale down 1dev/agent docker swarm service to 0 replicas so that no remote builds can be done anymore
2. Upgrade 1dev/server image in docker-compose and redeploy the 1dev/server docker service
3. Download the new Agent, build and push a new 1dev/agent image matching the version of 1dev/server
4. Update docker-compose again with new agent version and redeploy agent service.

Obviously step 3. is what I want to avoid and just pull from docker hub.

A different approach for an 1dev/agent docker image could be to just let it fetch the agent from 1dev/server when the 1dev/agent starts. When 1dev/server is updated the container could detect that and either terminate and be restarted by docker (which would mean the matching agent would be downloaded again automatically) or the current agent upgrade process could be triggered if the 1dev/agent image can make sure to not terminate itself after upgrade. So basically PID 1 must be always running while the container can still upgrade its containing agent.

State changed as code fixing the issue is committed

State changed as build #2259 is successful