I think I got it. This is because the got_revision_mapping is the wrong way around. This is a known technical dept. We map from deps-path -> property name, which is dumb. Like that, one dependency can have max one property. In case a chromium bot runs e.g. in webrtc and webrtc should be got_revision, we can't have got_webrtc_revision in the same time.
This explains why we never have both in the simulation. I assume in prod, the real bot_update script does some magic to emit both got_revision and got_webrtc_revision with the same value.
Cc: -machenb...@chromium.org iannucci@chromium.org Owner: machenb...@chromium.org Status: Started (was: Assigned)
I'm grabbing this for now, since this annoys me since a long time already. Will make it available again if my solution is not wanted.
Baked a first CL:
https://chromium-review.googlesource.com/c/483479
Kudos to you Michael! Looking forward to the progress. I'm unfortunately swamped with a lot of non-infra work right now so I don't have time to do the cleanup.
Rollout plan:
- Land
- Make roll CL into build and get approval
- Close the chromium tree
- Land roll
- Wait for one successful bot_update and check properties
- Open tree
In case of breakages:
- The roll can be immediately reverted
- Patch failures on revert would mean there was a new recipe test case in the meantime, just retrain and continue.
machenbach is this still relevant? it seems to be buildbot-agnostic, i.e. same problem occurs on LUCI? seems bot_update-specific, so moving to Infra>SDK
This is still not really finished and kindof left in an unclean state. Now we have a got_revision_mapping, and a reverse mapping. The idea was to drop the first...
But I won't be able to get to it soon.
Comment 1 by machenb...@chromium.org
, Apr 20 2017