Keep-alive during Jenkins restart (offline capability)

[bsingr]

Currently, after restarting Jenkins someone needs to reload the monitor manually.

To fix this we could do the monitor reloading in the background via ajax, wrap an iframe around it or apply some other tricks..

[jan-molak]

Wow Jens, this sounds really complicated! :)
I'm not sure if an "offline capability" is a good way to put it; Build Monitor needs to be fed information from Jenkins in order to function, but I think I understand what you mean.

I'm not using the standard Stapler JavaScript proxy directly; instead I hid it behind an "anti-corruption layer", which allowed me to introduce AJAX error handling - that's why you can see the "Sorry to bother you" error screen when you restart Jenkins and Build Monitor loses its connectivity with the mothership. This capability can of course be used in a much smarter way than just displaying an error message, but that's a place to start and a "Minimum Viable Product®" ;)

I decided to display an error message and a button that allows the user to manually reload the page, rather than doing this automatically, because of several reasons:

• Stapler JavaScript proxy generally speaking issues a token that the front-end app needs to use in order to communicate with the back-end. This token loses its validity upon a Jenkins restart, so a restart of the back-end requires a reload of the front-end
• If I reloaded the page instantaneously upon a Jenkins communication error, the user would most likely end up on a default "can'f find this page" error screen of their favourite web browser, and this probably wouldn't make them feel overly happy about the situation
• If instead I waited for a couple of minutes after a communication error happens and then reload the page (assuming that it's a Jenkins reboot that caused the issue), but then it turned out that it wasn't a reboot but for instance a dead WiFi connection - the user would end up in the same situation as described above. Again, not cool.
• Focusing on implementing a good error capturing mechanism and basic error handling seemed like a sensible compromise that delivers a decent user experience and provides a base for a more sophisticated solution :)

I think that the ideal implementation would be the following:

• if a network communication error happens (Jenkins returns a "0" status code) - this means that either your network is dead or Jenkins is being restarted; we can hope that that's the former and Stapler's token is still valid. We can then try to re-establish the connection, informing the user that that's what we're doing
• if instead Jenkins returns 404 it means that it has been restarted and the token is no longer valid. Yet, because we know that Jenkins is available we can safely reload the front-end automatically.
• of course Jenkins can also return a 50x, which means that it's dead after the restart, and the user should be advised to contact their Jenkins admin person.

What do you think?

[bsingr]

Wow, I appreciate your engagement :)

First of all, agree, "offline capability" is misleading.

I didn't know about Stapler (my Jenkins/Java background is not very strong), but I can imagine what the token is about.

It's great to hear that you have done some "Sorry to bother you" error page - I didn't know this, maybe there is an issue in our environment that prevents that page from being rendered.

I totally agree with your "ideal implementation".

[jan-molak]

Engagement is a necessary ingredient of any good software ;)

Basically, when a network connection drops Build Monitor should display an error page; it surprises me that you can't see it... What version are you using? I introduced that feature pretty early on.