force dry run button? or refine how they work with rebases? |
|||||||||||
Issue descriptionhttps://skia-review.googlesource.com/c/13970/ PS1 is a CL rebased against Skia head, something checked in. The CQ dry run ran fine. I realized it didn't make sense to land without some other code first, so I wrote up a new CL, and then rebased the first CL onto it, creating PS2. Clicking CQ dry run then says there's nothing to do... a dry run ran recently enough, and we didn't change any code, only rebased. This surprised me. I was expecting that rebasing on another pending CL would invalidate the CQ results and re-run the dry run. This is low priority. It's rare that this comes up, and I don't mind making some sort of trivial change to the CL to manually invalidate the dry run results. In this case I'll probably just wait until the other CL lands anyway. But it might be neat to either have a button to invalidate those results and run again, or to make sure we're treating rebase-on-pending-CL how we want to be.
,
Apr 20 2017
I suspect this is something to fix on the chrome-infra end.
,
Apr 20 2017
,
Apr 20 2017
,
Apr 21 2017
Yeah, this is definitely an interesting idea. tandrii@, do you have thoughts? I don't think there's a way to "invalidate" the previous jobs, the CQ just decides whether they're valid based on which patchset they're from as opposed to any data on the buildbucket tasks themselves. The most obvious solution here is to change both the CQ's and the buildbucket plugin's validity logic to reject rebases onto anything other than the target ref. I'm not sure how that would happen. This is definitely something to think about, but as you say, rare, so I'm going to put it in Afterglow.
,
Apr 21 2017
I already filed bug for this a while ago, titled don't reuse tryjobs if the relationship changed. But I can't find it. So, I will keep this bug. It definitely deserves to be in CQ daemon tracker.
,
Apr 21 2017
And, in my experience of pipelining lots of cls this happens daily.
,
Jun 2 2017
,
Jul 19 2017
,
Aug 31 2017
,
Aug 31 2017
,
Jan 3 2018
Removing Milestone-Afterglow, as it has ceased to have meaning. More refined milestones may be added back in the near future.
,
Jan 5 2018
Duping into 686115 which is also about the difference between "rebase on top of same parent" and "rebase on top of different parent" having very different potential consequences, but being treated the same by Gerrit (both "trivial rebase") and the CQ (reusing jobs). |
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by rmis...@google.com
, Apr 20 2017