Do you mean onedev agent? If so, it talks to server via websocket. Agent code may gets improved frequently, not only for protocol, and every change to agent code or its dependency will increase agent version.

Normally agent can downgrade automatically when server is downgraded, as the protocol between agent/server seldomly changes. Once protocol changes the downgrade will not be possible.

yes, i was talking about agent. thanks for your answer.

Because the tanuki wrapper you use is not compatible with Nixos, i made a workaround to setup each ondev-agent as systemd user services :

    ## myapp1 onedev agent
    systemd.user.services.onedev-agent-myapp1= {
        enable = true;
        unitConfig = { ConditionUser = "myapp1"; };
        wantedBy = [ "default.target" ];
        after = [ "network.target" ];
        description = "onedev-agent-myapp1";
        path = [ config.system.path ];
        serviceConfig =
        let
            java = "${pkgs.jdk11_headless}/bin/java";
        in
        {
            ExecStart = "${java} -cp '%h/onedev-agent/lib/1.8.17/*' io.onedev.agent.Agent";
            Type = "simple";
        };
    };

## myapp2 onedev agent
    systemd.user.services.onedev-agent-myapp2= {
        enable = true;
        unitConfig = { ConditionUser = "myapp2"; };
        wantedBy = [ "default.target" ];
        after = [ "network.target" ];
        description = "onedev-agent-myapp2";
        path = [ config.system.path ];
        serviceConfig =
        let
            java = "${pkgs.jdk11_headless}/bin/java";
        in
        {
            ExecStart = "${java} -cp '%h/onedev-agent/lib/1.8.17/*' io.onedev.agent.Agent";
            Type = "simple";
        };
    };
    ...

Problem : the execStart path contains the library version number. each agent update, i need to edit this config and deploy to nixos.

Solution (not working) : i try to create and file soft link current which point to 1.8.17. But on upgrade, the agent simply delete all files under lib directory so my hack does not work.

So back to manual upgrade each time...

That is painful. How about not installing agent on this OS, but ssh into it to do things (OneDev has a ssh command step)?

(OneDev has a ssh command step)?

😮 😯 😲 😱 😱 😱 😱 😱

I subscribe to all events since 4 years, reading almost everything except one time, my last holidays 23", April end of month... and you release a such lacking killer feature (SSH and SCP steps) this exact moment 😅

Thanks Robin !!

Glad to see this makes your life easier, 😃

During our outage this morning, one of my coworker was wondering the state of the commercial version you want to propose. I think he has more precisely the high availability feature in mind.

i admit it's a good question ?

Yes, HA feature in commecial version can remit this issue, at least give a good copy in such events (it is very unlikely that two copies are broken). I finished all features of commercial version, but want to test it more, plus doing some polishments. Plan to get it ready before end of this year.

Yes, HA feature in commecial version can remit this issue, at least give a good copy in such events (it is very unlikely that two copies are broken). I finished all features of commercial version, but want to test it more, plus doing some polishments. Plan to get it ready before end of this year.

HA is based on Hazelcast, right? I also used it once. Just be aware that everything that is not part of the CP-subsystem of Hazelcast is actually AP (CAP theorem). So if connectivity issues between Hazelcast nodes exist it will favor availability at the cost of consistency. So you might want to test how your solution behaves if you have multiple OneDev instances behind a round robin load balancer and network quality between OneDev nodes is bad.

HA is based on Hazelcast, right? I also used it once. Just be aware that everything that is not part of the CP-subsystem of Hazelcast is actually AP (CAP theorem). So if connectivity issues between Hazelcast nodes exist it will favor availability at the cost of consistency. So you might want to test how your solution behaves if you have multiple OneDev instances behind a round robin load balancer and network quality between OneDev nodes is bad.

Yes, that is true. It does sacrify consistency in that case, but I think this should be tolerable for systems like OneDev for a short while (will send email to administrator to raise attention as soon as some nodes are disconnected). The consequence is that one may push to serverA, and another may push to serverB, and when serverA and serverB reconnects, serverA's copy may override serverB (or vice versa). For CI part, the same scheduled job may gets running twice.