View Issue Details

IDProjectCategoryView StatusLast Update
0004626Talerdeployment and operationspublic2018-04-15 20:33
ReporterFlorian DoldAssigned ToMarcello Stanisci 
PrioritynormalSeverityfeatureReproducibilityhave not tried
Status closedResolutionfixed 
Product VersionSVN HEAD 
Target Version0.5Fixed in Version0.5 
Summary0004626: build automation needs more logging
DescriptionLooks
 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.
TagsNo tags attached.

Activities

Marcello Stanisci

2018-01-09 13:39

manager   ~0012753

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?

Florian Dold

2018-01-09 13:41

manager   ~0012754

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".

Marcello Stanisci

2018-01-09 13:55

manager   ~0012755

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.

Marcello Stanisci

2018-01-09 17:20

manager   ~0012757

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?

Florian Dold

2018-01-09 23:44

manager   ~0012758

That's exactly what I meant: more helpful logging in case something goes wrong.

So I guess we can mark this as fixed!

Issue History

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 View Revisions
2016-11-15 15:59 Christian Grothoff Product Version => SVN HEAD
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
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 => 0.5
2018-04-15 20:33 Christian Grothoff Status resolved => closed