Train should reconfigure at the start of every build job.

[Robert Bruce Park]

A major usability bug we're having with the train right now is that people don't seem to understand that you need to reconfigure the silo after making changes in bileto (this seems to be a symptom of the larger misconception that people don't understand that bileto is a drop-in replacement for the spreadsheet, and all the same jenkins-isms that were necessary before bileto are still necessary now).

HOWEVER, the only reason the train could never request from the spreadsheet in the past was that the firewall didn't allow for this. Since bileto is inside the firewall, it's perfectly reasonable for jenkins to access it (and indeed jenkins is already pushing statuses this way).

Make the build job "reconfigure" at the start of every build, effectively making sure that every build always has the latest info from bileto, so there will no longer be any issues of information in bileto not being communicated to jenkins.

[Robert Bruce Park (robru)]

I worked a bit on this today, here's my findings:

The idea of "reconfiguring at the start of every build" is an incredibly crude approach, it would make the workflow look like this:

1. "assign" a silo, jenkins queries bileto for silo state, processes it, saves it as json on disk.

2. "build" a silo, jenkins queries bileto for silo state, processes it again, saves it as json on disk again, then reads the json back and continues with build as per usual.

So then I got the brilliant idea to modify SiloState class to just read from bileto instead of using any json on disk at all. This is the best solution, but it hit a couple blockers:

1. Dashboard depends on those static json files in order to display silo state.

2. Having SiloState support both "json on disk" and "bileto API" was somewhat clunky/untenable.

So I think the proper way to work through this issue is:

1. Expand "Requests" page so that it shows all the same info as dashboard. Considering that status & MP lists are already there, I think the only thing left to do is add build/publish links really.

2. Once Requests page is confirmed to be a superset of current Request + Dashboard pages, dashboard can simply be deleted, along with the rsync logic that copies json files from jenkins into bileto unit.

3. With that out of the way, SiloState can simply be changed to reference bileto as authoritative rather than "json blobs on disk".

4. We enter a new Utopia in which nobody ever has to reconfigure a silo ever again.