Hi, Chase :)

Since Chromium/src's HEAD moves fast, the older the try build => the older HEAD it run against => the less signal there is from it.
OTH, re-running builds all the time is too expensive. So, CQ compromises by re-using up to 24h old try job.

Hence, WAI.

Hi Andrii!

Can you point me to where this is documented?

Re-opening for an answer to the question in comment 3.

i'm afraid only in CQ itself:
https://chrome-internal.googlesource.com/infra/infra_internal/+/879c9ae727a60c8a615a3199012a7491bc47898e/infra_internal/services/cq/verification/try_job_utils.py#57

but per issue 753103, it should be configurable in cq.cfg of each project.

Thanks for following up.  I'm optimizing for having valid CQ+1 results before pressing CQ+2 so my CL doesn't require a lot of tending to, and having this visible in the UI somewhere would help with that.

> I'm optimizing for having valid CQ+1 results before pressing CQ+2 so my CL doesn't require a lot of tending to, and having this visible in the UI somewhere would help with that.


Yep, this is exactly what CQ+1 was made for. Reasonable FR, updated description and title. I think it's reasonable to consider this in Q1.

What’s the problem we are trying to solve? The confusion?
Would a user be confused if CQ’s message explicitly said that existing tryjobs are stale and it has to rerun new ones?

It would help me to know for how much longer I can CQ+2 and re-use CQ+1 dry run results.  In the case of the CL I mention in comment 0, I had a dry run on Friday, then planned to land on Monday re-using those results.  But the results were stale by Monday.  It wasn't clear when they became stale.

If I'd seen on Friday the CQ dry run was good until <some time on Saturday>, I'd have planned to have another dry run ready for Monday when I was ready to CQ+2.  Including this somewhere in the CQ comments on the CL would cover this case.

https://crrev.com/c/1352623 seems to have the same issue.  I CQ+1'd yesterday afternoon so I could CQ+2 this morning and re-use the dry run results, but it appears to have started runs on all of the bots.  Can you tell if that's what happened?

Is there a way to force all of the bots to run so the results will be recent?  Maybe if I upload a new patchset and CQ+1 on that patchset?

Nodir@ there are two aspects here: incorrect prediction (for lack of recency information) and confusion (why aren't green tryjobs re-used?).
CQ messaging will only solve the confusion, well, assuming users actually read comments down at the bottom.

OTH, having visual indication which tryjobs are stale will solve both aspects of a problem.

cmp@ I personally have just been (re)-hitting CQ+1 on CLs i'm expecting a code review soon. It doesn't guarantee that all tryjobs remain fresh by the time CQ+2 is hit, but it makes this more likely. Uploading new (and non-trivially differing) patchset and CQ+1 will also work, but is more expensive to our capacity :)

I agree that a green box entails a positive "yes, we are good here", and it may be a lie.

> hardcode 24h
Since this is more about UX, I think it is ok to hardcode 24h for now and say "these build results are old and CQ is **likely** to ignore them". This does not pretend to be precise, so it is not a lie... we can make it precise when CQ has a proper API.