> #71
Here is what happens I think:

Gerrit sets changes buildbucket parameter to 
[
  {
    "branch": "master",
    "author": {
      "email": "machenbach@chromium.org"
    },
    "url": "https://chromium-review.googlesource.com/c/439324/7",
    "project": "v8/v8",
    "repo_url": "https://chromium.googlesource.com/v8/v8",
    "revision": "0e5cd6720953d37d754a9c028a1e174327533aa6"
  }
]
see, https://cr-buildbucket.appspot.com/_ah/api/buildbucket/v1/builds/8983854574173728352

=> buildbot sets special revision property to 0e5cd6720953d37d754a9c028a1e174327533aa6
=> bot_update fails because it expects revision property to be the ref that it fetches/checks out

In contrast, rietveld doesn't specify revision in changes
https://cs.chromium.org/chromium/infra/appengine/chromium_rietveld/codereview/buildbucket.py?l=239

Two options:
a) Don't set revision field of change object
b) Set it to the refs/changes/CC/CCCCCC/P value

Do we think (b) would work? It seems more intellectually pure, but if bot_update can't directly fetch hashes I'm not sure it'll do that correctly either.

(Third option: make bot_update handle (i.e. directly fetch) unrecognized hashes in the revision field. That sounds like a lot of work. Even gclient can't do that right now.)

Turns out this affects manually-triggered chromium jobs too:
CL: https://chromium-review.googlesource.com/c/457023/
Failed manual tryjob run: https://luci-milo.appspot.com/buildbot/tryserver.chromium.linux/linux_chromium_rel_ng/418394

https://chromium-review.googlesource.com/461723

The following revision refers to this bug:
  https://chromium.googlesource.com/infra/gerrit-plugins/buildbucket/+/f47ee63df97185ac0667ea7ea42e8f3aaa121ebf

commit f47ee63df97185ac0667ea7ea42e8f3aaa121ebf
Author: Aaron Gable <agable@chromium.org>
Date: Tue Mar 28 21:05:41 2017

Don't set extraneous change parameters on build

When we set the revision parameter, bot_update reads that
and it overrides all of the various patch_* parameters that
we also set. This causes bot_update to act as though it is
checking out a revision from master, instead of a pre-commit
patch, and ends up failing.

These parameters are not set of jobs triggered by the CQ.

Bug:  706135 
Change-Id: If7459b09b363410619720f1583aed12577fc88d9
Reviewed-on: https://chromium-review.googlesource.com/461723
Reviewed-by: Nodir Turakulov <nodir@chromium.org>

[modify] https://crrev.com/f47ee63df97185ac0667ea7ea42e8f3aaa121ebf/src/main/resources/static/cr-tryjob-picker.js

Import: http://cl/151504969

Leaving open until deployment.

The following revision refers to this bug:
  https://chromium.googlesource.com/infra/gerrit-plugins/buildbucket/+/6bf275ea45be632d6fee4c66f8c0ee554f53dbc9

commit 6bf275ea45be632d6fee4c66f8c0ee554f53dbc9
Author: Aaron Gable <agable@chromium.org>
Date: Wed Mar 29 00:39:45 2017

Update tests for buildbucket parameter change

Bug:  706135 
Change-Id: Ic70970a302d7c41e72e5585ffcbb02c26c281f94
Reviewed-on: https://chromium-review.googlesource.com/461255
Reviewed-by: Andrew Bonventre <andybons@chromium.org>

[modify] https://crrev.com/6bf275ea45be632d6fee4c66f8c0ee554f53dbc9/test/cr-tryjob-picker_test.html

I think I ran into the same problem when trying to run a Skia patch on Chromium trybot: https://build.chromium.org/p/tryserver.v8/builders/v8_linux64_rel_ng/builds/23447

The link in comment 11 is likely wrong...

Oops yes. The right link is: https://build.chromium.org/p/tryserver.blink/builders/linux_trusty_blink_rel/builds/7220

Yep, looks like the same thing. Hopefully this will be fixed by a deployment today.

Gerrit backend deployment has completed but it looks like latest polygerrit (including latest buildbucket plugin) hasn't happened yet. Hopefully today.

Hmm, somebody retried the tryjob on https://chromium-review.googlesource.com/c/439324 that wasn't me. Was it for testing this? Looks like it worked... if it was triggered from UI.

The weird thing is that I got an email confirmation about the tryjobs, though I didn't trigger them. I think in rietveld, the email goes to the person triggering, but not sure now.

That was me! I was testing for this.

I actually did two imports of the buildbucket plugin. I believed that the latest deployment didn't contain either because it isn't showing the UI changes that I made in the second import. But it actually looks like the deployment started between the two imports, and contains the first CL which fixed this bug.

Huzzah!