Page constantly refreshes during build about gitness HOT 19 CLOSED

interesting, this would indicate websocket connections are being rejected:
https://github.com/drone/drone/blob/master/pkg/template/pages/repo_commit.html#L64

any chance your app is sitting behind some sort of proxy?

from gitness.

Ah, I wasn't aware WebSockets were necessary. I am behind a reverse proxy which isn't currently configured to work with WebSockets. I'll update the config and see if I can get that working. If the refresh is intended to be a fallback, I don't think it works well as it just means I have no chance to see any output at all.

from gitness.

what proxy server are you using? all websockets connect to /feed. If you're using nginx perhaps this will help:

server {
       ...
       ...
    location /feeds {
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
                proxy_pass        http://localhost:8000;
                proxy_set_header  X-Real-IP  $remote_addr;
    }
}

from gitness.

Yup, exactly what I tried. (Although in your example you have /feeds instead of /feed.) Still getting the same issue. I'll try later in the week without the proxy and see if I still have the same issue. I'm still wondering if a constant page refresh is the intended fallback because it's a pretty poor experience.

from gitness.

agreed, the constant refresh should be avoided. it was a quick hack for us to refresh the page when the build completed ... instead we should add a second websocket that listens for the build to complete and then update the page content via javascript code

from gitness.

Even a delay of a few seconds would be much more helpful so I at least have a chance to see where the build is at.

from gitness.

well, the refresh is caused by the websocket failure. so even if we added a delay, you wouldn't see the build output because that data comes from the websocket, and isn't persisted to the database until the build is complete.

I think we can definitely fail more gracefully and avoid the refresh, but you will definitely get a sub-optimal experience if websockets aren't working

from gitness.

Ah, understood. It would be nice to be able to just periodically poll the server and refresh the page only once the build has completed.

from gitness.

I actually stumped on this until I checked my nginx version and it was still v1.2.9 :D
Apparently proxying websocket support was added at 1.3.13. It works after I updated it to the latest version.

On the bright side, I made a rough stub on how we can use ajax polling to retrieve build output.
https://github.com/fudanchii/drone/compare/polling

But I think this isn't really necessary, as it is rather designed as a fallback when websocket is not available (yes, I commented out the websocket portion of the javascript right now for testing), and not when websocket isn't working (i.e. when browser reports websocket is available, but then got hang up waiting for response). Definitely one can argue that all popular browsers already support websocket :)

from gitness.

I think we should add sample nginx configuration to our documentation (drone.readthedocs.org) as well as the required minimum nginx version.

I agree with @fudanchii

I probably would reject a patch that added long polling. Web sockets are supported across all major browsers. They are also supported by major proxy servers. I view websockets as a system requirement. I don't want to complicate our (already complex) codebase to support legacy fallbacks. Sorry to be a downer :(

@fudanchii would you mind sending me your nginx config so I can add it to the docs?

from gitness.

Sure, it's pretty much standard:

server {
    listen *:80;
    server_name ci.fudanchii.net;

    location / {
        proxy_pass http://127.0.0.1:8898;
        proxy_set_header  X-Real-IP  $remote_addr;
        proxy_set_header  X-Forwarded-For  $remote_addr;
        proxy_set_header Host $host;
    }

    # May want to set this location to make
    # status-badge work with GitHub caching proxy
    location ~ ^/img/build_.+\.png$ {
        proxy_pass http://127.0.0.1:8898;
        proxy_set_header  X-Real-IP  $remote_addr;
        proxy_set_header  X-Forwarded-For  $remote_addr;
        proxy_set_header Host $host;
        add_header Cache-Control no-cache;
    }

    # Proxy for websockets
    location = /feed {
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header Host $http_host;

        proxy_pass http://127.0.0.1:8898;
        proxy_redirect off;

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

from gitness.

@fudanchii Ha! Thanks for pointing that out. It hadn't crossed my mind to check the version. Likely the same issue on my end.

from gitness.

I've documented both the nginx version and configuration:
http://drone.readthedocs.org/en/latest/install.html#proxy-server

from gitness.

We run drone behind an ELB, which is a PITA to set up websockets on, so for now we've just lived with this.

After using drone for a good six months now I constantly think to myself when we run into this reloading issue: are websockets worth the operational cost it incurs on users (and the cost to drone maintainers of documenting proxy settings)? I could see replacing them with long-polling as a way to reduce complexity in a lot of places.

from gitness.

This behavior is fixed in the exp branch. It no longer refreshes the page when a websocket fails to connect or drops a connection. It is unfortunate that ELB doesn't support websockets, however, I don't see us moving to a long polling model in Drone.

from gitness.

@bradrydzewski I think Rancher had this same issue and resolved it by implementing support for ProxyProtocol which ELB supports - Is this any option for Drone?
http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/enable-proxy-protocol.html

from gitness.

0.4 branch uses server sent events which is uses standard http and does not require a protocol upgrade like websockets. It will need to be tested, however, this may solve the issue with ELB.

from gitness.

hmmmm....I'm running the drone/drone:latest build from yesterday (9/13) and I was not getting streamed events in the web view when doing a build behind an AWS elb.
I see there is a 0.4 branch, should I be building that and using it instead?

from gitness.

0.4 is not stable, however, it isn't far from being released either. I wouldn't recommend using it quite yet, but since release is not far off we aren't making major changes to the stable channel

from gitness.