/cc @huitseeker, @rkuhn (Please let me know if I should CC someone else for each team that's using the bot.)
Note: not deployed yet, as there's a massive jenkins queue right now,
because of the switch to the new Scala PR validation jobs.
Automatically synch every 2 hours (randomly sampled).
Better toString for BuildStatus, drop unused fields.
Clean up embarrassing implementation of PLS SYNCH.
Assume we're watching jenkins if commit status exists.
I think our network karma is not affected negatively by this,
as the bug fixes above should massively offset the increase due to synching every two hours.
We used to distinguish whether the status was (success or error)
versus (failed or pending), but this doesn't really make sense: we
don't use failed to indicated jobs that failed to run for external
reasons and thus need to be restarted. In fact, the result of a job
that indicates an error (compile or test failure etc) is "FAILURE"
(and thus status.failed), so we should've been doing it the other
way around.
All of this is bogus: if there's a commit status, let's assume
we're watching the corresponding jenkins build. In case we miss it
due to some glitch, we'll catch it when we decide to randomly synch
(see earlier commit).
jsuereth
commented
11 years ago
Review by @jsuereth.
/cc @huitseeker, @rkuhn (Please let me know if I should CC someone else for each team that's using the bot.)
Note: not deployed yet, as there's a massive jenkins queue right now, because of the switch to the new Scala PR validation jobs.
I think our network karma is not affected negatively by this, as the bug fixes above should massively offset the increase due to synching every two hours.
We used to distinguish whether the status was (success or error) versus (failed or pending), but this doesn't really make sense: we don't use
failedto indicated jobs that failed to run for external reasons and thus need to be restarted. In fact, the result of a job that indicates an error (compile or test failure etc) is "FAILURE" (and thusstatus.failed), so we should've been doing it the other way around.All of this is bogus: if there's a commit status, let's assume we're watching the corresponding jenkins build. In case we miss it due to some glitch, we'll catch it when we decide to randomly synch (see earlier commit).