|
|
DescriptionAdd some useful information to trooper doc.
BUG=skia:
NOTRY=true
DOCS_PREVIEW= https://skia.org/?cl=1308253005
Committed: https://skia.googlesource.com/skia/+/fbf908c857069b8988a3b0e7c5e706d8d392e898
Patch Set 1 : #
Total comments: 12
Patch Set 2 : Update based on review. #Patch Set 3 : Update with info about Chrome infra machines. #Patch Set 4 : Minor edits. #Messages
Total messages: 13 (4 generated)
Patchset #1 (id:1) has been deleted
benjaminwagner@google.com changed reviewers: + borenet@google.com, rmistry@google.com
LGTM with a few comments. https://codereview.chromium.org/1308253005/diff/20001/site/dev/sheriffing/tro... File site/dev/sheriffing/trooper.md (right): https://codereview.chromium.org/1308253005/diff/20001/site/dev/sheriffing/tro... site/dev/sheriffing/trooper.md:53: - Disconnected devices (these are detected as the "wait for device" step failing) No need to add to docs, but it's possible to make these auto-dismiss as well. The solution is to periodically check for a subsequent build on the same buildslave in which the step in question (update_scripts or wait-for-device) succeeded. https://codereview.chromium.org/1308253005/diff/20001/site/dev/sheriffing/tro... site/dev/sheriffing/trooper.md:57: failing. More detail: All "failed to execute query" alerts are lumped into a single alert, which is why the failed query which initially triggered the alert may not be failing any more but the alert is still active because another query is failing. https://codereview.chromium.org/1308253005/diff/20001/site/dev/sheriffing/tro... site/dev/sheriffing/trooper.md:65: - TODO(borenet): slave11-c3 I'm actually not sure where this one is. This runs our presubmit trybot. https://codereview.chromium.org/1308253005/diff/20001/site/dev/sheriffing/tro... site/dev/sheriffing/trooper.md:94: `TESTING_SLAVENAME=<device name> make start`. This should be <slave name> https://codereview.chromium.org/1308253005/diff/20001/site/dev/sheriffing/tro... site/dev/sheriffing/trooper.md:97: `~/skiabot-slave-start-on-boot.sh` after reboot. Don't do this without running `ps aux | grep python` to ensure that neither buildbot or gclient are running. Sometimes it's just slow to sync before launching the buildbot slave scripts.
LGTM Great job compiling this Ben! https://codereview.chromium.org/1308253005/diff/20001/site/dev/sheriffing/tro... File site/dev/sheriffing/trooper.md (right): https://codereview.chromium.org/1308253005/diff/20001/site/dev/sheriffing/tro... site/dev/sheriffing/trooper.md:53: - Disconnected devices (these are detected as the "wait for device" step failing) On 2015/09/03 12:23:05, borenet wrote: > No need to add to docs, but it's possible to make these auto-dismiss as well. > The solution is to periodically check for a subsequent build on the same > buildslave in which the step in question (update_scripts or wait-for-device) > succeeded. It will be useful to file a tracking bug for this. Eric should probably file it since he knows the most about it. https://codereview.chromium.org/1308253005/diff/20001/site/dev/sheriffing/tro... site/dev/sheriffing/trooper.md:65: - TODO(borenet): slave11-c3 On 2015/09/03 12:23:05, borenet wrote: > I'm actually not sure where this one is. This runs our presubmit trybot. Ben, this is a good question for the chrome-infra IRC channel: https://comlink.googleplex.com/chrome-infra (good link to bookmark)
On 2015/09/03 12:30:27, rmistry wrote: > LGTM > > Great job compiling this Ben! > > https://codereview.chromium.org/1308253005/diff/20001/site/dev/sheriffing/tro... > File site/dev/sheriffing/trooper.md (right): > > https://codereview.chromium.org/1308253005/diff/20001/site/dev/sheriffing/tro... > site/dev/sheriffing/trooper.md:53: - Disconnected devices (these are detected as > the "wait for device" step failing) > On 2015/09/03 12:23:05, borenet wrote: > > No need to add to docs, but it's possible to make these auto-dismiss as well. > > The solution is to periodically check for a subsequent build on the same > > buildslave in which the step in question (update_scripts or wait-for-device) > > succeeded. > > It will be useful to file a tracking bug for this. Eric should probably file it > since he knows the most about it. > Filed https://code.google.com/p/skia/issues/detail?id=4292 > https://codereview.chromium.org/1308253005/diff/20001/site/dev/sheriffing/tro... > site/dev/sheriffing/trooper.md:65: - TODO(borenet): slave11-c3 > On 2015/09/03 12:23:05, borenet wrote: > > I'm actually not sure where this one is. This runs our presubmit trybot. > > Ben, this is a good question for the chrome-infra IRC channel: > https://comlink.googleplex.com/chrome-infra > (good link to bookmark) That should be in this doc as well. It's not uncommon for us to have problems caused by upstream failures, and the IRC channel gives us visibility into that.
PTAL https://codereview.chromium.org/1308253005/diff/20001/site/dev/sheriffing/tro... File site/dev/sheriffing/trooper.md (right): https://codereview.chromium.org/1308253005/diff/20001/site/dev/sheriffing/tro... site/dev/sheriffing/trooper.md:53: - Disconnected devices (these are detected as the "wait for device" step failing) On 2015/09/03 12:30:27, rmistry wrote: > On 2015/09/03 12:23:05, borenet wrote: > > No need to add to docs, but it's possible to make these auto-dismiss as well. > > The solution is to periodically check for a subsequent build on the same > > buildslave in which the step in question (update_scripts or wait-for-device) > > succeeded. > > It will be useful to file a tracking bug for this. Eric should probably file it > since he knows the most about it. Added bug link. https://codereview.chromium.org/1308253005/diff/20001/site/dev/sheriffing/tro... site/dev/sheriffing/trooper.md:57: failing. On 2015/09/03 12:23:05, borenet wrote: > More detail: All "failed to execute query" alerts are lumped into a single > alert, which is why the failed query which initially triggered the alert may not > be failing any more but the alert is still active because another query is > failing. Done. https://codereview.chromium.org/1308253005/diff/20001/site/dev/sheriffing/tro... site/dev/sheriffing/trooper.md:65: - TODO(borenet): slave11-c3 On 2015/09/03 12:30:27, rmistry wrote: > On 2015/09/03 12:23:05, borenet wrote: > > I'm actually not sure where this one is. This runs our presubmit trybot. > > Ben, this is a good question for the chrome-infra IRC channel: > https://comlink.googleplex.com/chrome-infra > (good link to bookmark) Added IRC channel. Updated info on chrome infra based on discussion. https://codereview.chromium.org/1308253005/diff/20001/site/dev/sheriffing/tro... site/dev/sheriffing/trooper.md:94: `TESTING_SLAVENAME=<device name> make start`. On 2015/09/03 12:23:05, borenet wrote: > This should be <slave name> Done. https://codereview.chromium.org/1308253005/diff/20001/site/dev/sheriffing/tro... site/dev/sheriffing/trooper.md:97: `~/skiabot-slave-start-on-boot.sh` after reboot. On 2015/09/03 12:23:05, borenet wrote: > Don't do this without running `ps aux | grep python` to ensure that neither > buildbot or gclient are running. Sometimes it's just slow to sync before > launching the buildbot slave scripts. Done.
LGTM
On 2015/09/03 15:42:18, borenet wrote: > LGTM lgtm
The CQ bit was checked by benjaminwagner@google.com
The patchset sent to the CQ was uploaded after l-g-t-m from borenet@google.com Link to the patchset: https://codereview.chromium.org/1308253005/#ps80001 (title: "Minor edits.")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1308253005/80001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1308253005/80001
Message was sent while issue was closed.
Committed patchset #4 (id:80001) as https://skia.googlesource.com/skia/+/fbf908c857069b8988a3b0e7c5e706d8d392e898 |