View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004626 | Taler | deployment and operations | public | 2016-08-24 15:07 | 2018-04-15 20:33 |
| Reporter | Florian Dold | Assigned To | Marcello Stanisci | ||
| Priority | normal | Severity | feature | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Product Version | git (master) | ||||
| Target Version | 0.5 | Fixed in Version | 0.5 | ||
| Summary | 0004626: build automation needs more logging | ||||
| Description | Looks like recently buildbot shut down the live demo. Unfortunately it's not easy to see what happened, since we don't do a good job with logging yet. | ||||
| Tags | No tags attached. | ||||
|
|
By itself, Buildbot does log things; there is a twistd.log file in its installation directory where you can see what happens via Pythonic logs. I agree that it is quite hidden and undocumented, but logging does occur. Did you mean something more precise with this issue? Like we should render those logs from Buildbot somewhere more easily accessible? |
|
|
E.g. the switcher checks don't actually print the error that happened (e.g. response code/code, or timeout), they just say something like "blog not working". |
|
|
Okay, you refer to those checks: https://git.taler.net/deployment.git/tree/buildbot/checks.sh, right? They were born to just check if services got correctly restarted, so they have this "works or not" logging attitude. And if a service didn't restart, then we can't get much diagnostics from it. Actually, once you run those checks, your code did _not_ fail to both compile and test. In the worst case one test got skipped, which does not say too much in terms of logging either. In other words, once you run those checks, everything is (almost) fine, so you can't pick errors that obviously. And also, there was the Selenium test once which was able to go deeper and see what was wrong. If then you ask to see just the HTTP status code, or "timeout occurred", then yes this can be easily done. |
|
|
da38039 adds this: those checks now print http status code and other curl-specific errors like timeouts or failed-to-resolve names. Can we close here? |
|
|
That's exactly what I meant: more helpful logging in case something goes wrong. So I guess we can mark this as fixed! |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-08-24 15:07 | Florian Dold | New Issue | |
| 2016-09-26 14:33 | Christian Grothoff | Severity | major => feature |
| 2016-09-26 14:33 | Christian Grothoff | Status | new => confirmed |
| 2016-09-26 14:33 | Christian Grothoff | Description Updated | |
| 2016-11-15 15:59 | Christian Grothoff | Product Version | => git (master) |
| 2016-11-15 15:59 | Christian Grothoff | Target Version | => 0.3 |
| 2017-03-18 23:44 | Christian Grothoff | Target Version | 0.3 => |
| 2017-12-14 15:59 | Christian Grothoff | Target Version | => 0.7.1 |
| 2018-01-09 13:39 | Marcello Stanisci | Note Added: 0012753 | |
| 2018-01-09 13:41 | Florian Dold | Note Added: 0012754 | |
| 2018-01-09 13:55 | Marcello Stanisci | Note Added: 0012755 | |
| 2018-01-09 17:19 | Marcello Stanisci | Assigned To | => Marcello Stanisci |
| 2018-01-09 17:19 | Marcello Stanisci | Status | confirmed => assigned |
| 2018-01-09 17:20 | Marcello Stanisci | Note Added: 0012757 | |
| 2018-01-09 23:44 | Florian Dold | Note Added: 0012758 | |
| 2018-01-10 09:25 | Marcello Stanisci | Status | assigned => resolved |
| 2018-01-10 09:25 | Marcello Stanisci | Resolution | open => fixed |
| 2018-01-10 22:25 | Christian Grothoff | Fixed in Version | => 0.5 |
| 2018-01-10 22:25 | Christian Grothoff | Target Version | 0.7.1 => 0.5 |
| 2018-04-15 20:33 | Christian Grothoff | Status | resolved => closed |
