Chromiumdash: Potential inconsistencies in migrated repos |
|||||||
Issue descriptiontl;dr when we bootstrap on WebRTC, I think we'll see bad behavior milestones < M63: WebRTC recently migrated where their repo was located (see https://bugs.chromium.org/p/chromium/issues/detail?id=702199#c30). machenbach@ addressed this via commit parsing here: https://chrome-internal.googlesource.com/infra/infra_internal/+/6fca6930908741cd84967925b8c73e58664ac773 Note we had an unaddressed dependency in the front-end here: https://chrome-internal.googlesource.com/infra/infra_internal/+/master/appengine/chromiumdash/static/html/repository-behavior.html#26, we'll have to take care of that in some capacity (based on outcome here) However, version polling (e.g. associating a commit with a released version) relies on parsing buildspec DEPS; and WebRTC hasn't utilized the new repo structure in any release branch < M63 (e.g. see WebRTC config for initial M62 build here: https://chrome-internal.googlesource.com/chrome/tools/buildspec.git/+/master/releases/62.0.3202.0/DEPS#291). I think the way things are written now, as soon as we try to bootstrap a version like the one linked to, the version poller will try to grab the start / end hashes out of the buildspec, and fail to find them in the migrated repo, and bail out. I would say maybe we just ignore this, but it seems like we might run into this situation again, esp. if we add more repo support - and causing all old data to go incomplete might not be great. WDYT re: adding wrappers wherever we look up repo URLs so that they can point to either the new, or the old, repo based on milestone?
,
Oct 17 2017
What do you mean by bootstrap? I'm currently learning more about how chrome infra works, but I haven't heard that before. If there's any way we can make from..to work for git revision ranges, I'm all for it. I gather from above that it won't work if the range crosses the point where we switched from the subtree mirror to webrtc.googlesource.com. I don't feel I can contribute anything technically here, so if you want me to do anything you have to tell me what to do basically :) Edward knows more.
,
Oct 17 2017
Re 2: This is about Chromiumdash only. Bootstrap here means, what happens if we wipe the DB and start the app fresh (which will eventually happen when we migrate the staging app to prod). If you don't care much about Chromiumdash or about older commits in Chromiumdash then there's nothing to do here.
,
Oct 19 2017
I guess no one from the WebRTC team has escalated, so we can probably live with this for the beta launch. That said, we should likely get something sorted out here for the future before we forget about it, because this seems likely to come up again and it'd be good to have something in place rather than scrambling to accommodate later.
,
Oct 20 2017
If it fails cleanly before M63, we're fine with it I think. We'd be happy to see it work but I can hardly ask anyone to prioritize it.
,
Dec 5 2017
,
Mar 26 2018
v8 migrated their repos to a different format recently and now face the same challenge. Re-assigning this to machenbach@ to see how they want to proceed.
,
Apr 6 2018
We did? Could you elaborate? The original issue here was a repo migration of webrtc, but V8 never migrated their repo. Do you have an example about what's not working for V8?
,
Apr 6 2018
Oh, now I found the context in a related email. Maybe we shouldn't mix these things up. I'll file another bug for that. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by machenb...@chromium.org
, Oct 17 2017