Handle private & public cross dependent CLs more smartly, especially if tree is throttled |
||||||||||
Issue descriptionI have 2 cls: one private: https://chrome-internal-review.googlesource.com/#/q/272016 one public: https://chromium-review.googlesource.com/#/c/376882/ They depend on each other (one is the test CL for the other) both are marked Commit-Queue Ready. However, they are refused by the builder: 376882: @ 1:12am The Commit Queue failed to apply your change in https://uberchromegw.corp.google.com/i/chromeos/builders/master-paladin/builds/12231 . CL:376882 depends on CL:*272016, which was not eligible (wrong manifest branch, wrong labels, or otherwise filtered from eligible set). *272016: @ 3:17am The Pre-Commit Queue failed to apply your change in https://uberchromegw.corp.google.com/i/chromeos/builders/pre-cq-launcher/builds/7622 . CL:*272016 depends on CL:376882, which is not marked Commit-Queue>=+1. Why is the private CL non eligible? [blocking b:27849483]
,
Sep 2 2016
,
Sep 2 2016
I've now hit this twice and my whole chain needed to be marked Ready again. === See: https://chromium-review.googlesource.com/#/c/368476/ Patch Set 2: The Commit Queue failed to apply your change in https://uberchromegw.corp.google.com/i/chromeos/builders/master-paladin/builds/12238 . CL:368476 depends on CL:368475, which was not eligible (wrong manifest branch, wrong labels, or otherwise filtered from eligible set). Commit queue documentation: http://www.chromium.org/developers/tree-sheriffs/sheriff-details-chromium-os/commit-queue-overview === See https://chromium-review.googlesource.com/#/c/368477/ Patch Set 2: The Commit Queue failed to apply your change in https://uberchromegw.corp.google.com/i/chromeos/builders/master-paladin/builds/12237 . CL:368477 depends on CL:368476, which was not eligible (wrong manifest branch, wrong labels, or otherwise filtered from eligible set). Commit queue documentation: http://www.chromium.org/developers/tree-sheriffs/sheriff-details-chromium-os/commit-queue-overview
,
Sep 2 2016
Yes, this was the result of the tree throttling.
,
Sep 2 2016
@4: So I presume that bug is: if the tree is throttled, CQ should skimply skip CLs it doesn't want but it shouldn't mark them not ready.
,
Sep 2 2016
#0: Could the problem be that the CL was +2'ed by Dylan using his chromium account. I +2 it with my google account, it seems to have helped. The tree throttling could not have explained it failed 3 times.
,
Sep 2 2016
RE 5 yes that sounds right. Or, the harder fix, making the capping logic more intelligent so that it doesn't just filter out a random subset before computing CL dependencies. Note -- this was to some extend intentional, because we suspected that GoB is having more issues server side with the kernel repos (they are harder to gc) and we were seeing a lot more flake in git fetch of kernel. So, being mean to kernel stacks was to some extent intentional to avoid flake while catching up on the backlog.
,
Sep 13 2016
,
Sep 20 2016
,
Sep 27 2016
,
Dec 6 2016
Would be nice, but not a high priority.
,
Dec 11 2017
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 11 2017
I believe we fixed the throttled logic at some point, right? Marking as archived. |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by benhenry@chromium.org
, Sep 1 2016