For me it would be ideal if there was a command line argument to git cl
upload that triggered the right set of bots, too (like the current
--cq-dry-run)

qyearsley@ git cl already already what you want:
 * git cl try -m tryserver.xxx -b bot1 -b bot2
   will schedule just two builds.
 * git cl try-results 
   # (shameless plug), check out:
   #  watch -n 5 --color "git cl try-results --color"
   Currently, the output is for humans, but I'd +1 adding '--json FILE' and outputting build info in machine readable form.

cbiesinger@ Actually, there is something called PostUploadHook (+rmistry@), which I believe is used by SKIA for rebaselining as well.


So, what you could do is add something to PRESUBMIT.py which would be executed in PostUploadHook and which does "git cl try ..." on just right bots.

One thing to worry though: some people create lots of patchsets, and we don't have capacity to schedule CQ [dry] run for all these patchsets. So, if you go with PostUploadHook, ensure that the bots you are triggering have enough capacity and do not "eat" CQ capacity.

PostUploadHooks were added in  bug chromium:462208 

Created it for the purpose of automatically adding things to a CL's description based on which files were modified in the CL during upload.
Examples of current Skia use cases:
* If only documentation is changed then adds NOTRY and a link to where to preview the doc changes.
* If commit is in non master branch then adds NOTRY and NOTREECHECKS.
* Adds CQ_INCLUDE_TRYBOTS for some paths.

I believe the Perf team also uses it to automatically add CQ_INCLUDE_TRYBOTS to run telemetry benchmarks.

Thanks Ravi and Andrii, these things sound helpful.

It's definitely possible that in the future we may want to do a post-upload hook to trigger layout test try jobs on some set of CLs that may affect layout test results.

For now, I think the next step may just be to make it more convenient to start the necessary try jobs -- in the blink-dev thread Robbie suggested making `webkit-patch rebaseline-cl` do that, so I'm trying that out now (https://codereview.chromium.org/2271463002).

Christian, for your workflow does using a big git cl try command like the following work?
    git cl try -b linux_precise_blink_rel -b linux_trusty_blink_rel \
      -b mac10.9_blink_rel -b mac10.10_blink_rel \
      -b mac10.11_blink_rel -b mac10.11_retina_blink_rel \
      -b win7_blink_rel -b win10_blink_rel

Making "webkit-patch rebaseline-cl" do that probably works better for my workflow :) But yes.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/acfc1b0b164003d71a717198cec888a52fc1f1c8

commit acfc1b0b164003d71a717198cec888a52fc1f1c8
Author: qyearsley <qyearsley@chromium.org>
Date: Tue Aug 23 17:23:59 2016

Change rebaseline-cl command to trigger any necessary try jobs.

BUG= 639533 

Review-Url: https://codereview.chromium.org/2271463002
Cr-Commit-Position: refs/heads/master@{#413770}

[modify] https://crrev.com/acfc1b0b164003d71a717198cec888a52fc1f1c8/third_party/WebKit/Tools/Scripts/webkitpy/tool/commands/rebaseline_cl.py
[modify] https://crrev.com/acfc1b0b164003d71a717198cec888a52fc1f1c8/third_party/WebKit/Tools/Scripts/webkitpy/tool/commands/rebaseline_cl_unittest.py
[modify] https://crrev.com/acfc1b0b164003d71a717198cec888a52fc1f1c8/third_party/WebKit/Tools/Scripts/webkitpy/w3c/update_w3c_test_expectations.py

Update: after that CL, there are several things that are not working quite right:
 - If there are no try jobs started yet, it failing to start any try jobs because android_blink_rel is on a different master from the rest. http://crrev.com/2269253002 should fix this.
 - If some try jobs are already started (but not finished), webkit-patch rebaseline-cl will start new ones.

In order to fix the second problem, I do think that adding a machine-readable output from git cl try-results would be nice; filed  issue 640354  for this.

Note, r413770 made it so that webkit-patch rebaseline-cl starts try jobs on the relevant bots if no jobs had been started yet, which is what I was originally thinking when I opened this bug.

I don't think that this is the best way that things can be, though.

Potentially, we could add another webkit-patch command or script under Tools/Scripts that is specifically for triggering try jobs. But, this adds yet another script/tool, and really this would just be a convenience for running git cl try. cbiesinger@, what do you think?

In any case, the higher-priority change to webkit-patch rebaseline-cl now is  issue 642980 .

To me, that implementation as it is seems fine -- another webkit-patch command or different script wouldn't really be easier, IMHO. Integration into "git cl upload" might be useful but I'm fine with running webkit-patch rebaseline-cl.

Alright, marking this particular bug as "fixed" for now.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0c65f8e43c6cebc7214fdf1d00dec86de2779c44

commit 0c65f8e43c6cebc7214fdf1d00dec86de2779c44
Author: qyearsley <qyearsley@chromium.org>
Date: Fri Oct 28 18:33:02 2016

rebaseline-cl: trigger all try jobs in one invocation of git cl try.

Previously, try jobs had to be triggered one by one using git cl try because of  http://crbug.com/640740 ; once that's fixed and most people have an updated copy of depot_tools, then this could be committed.

This makes triggering try jobs using webkit-patch rebaseline-cl faster.

BUG= 639533 

Review-Url: https://codereview.chromium.org/2452113002
Cr-Commit-Position: refs/heads/master@{#428434}

[modify] https://crrev.com/0c65f8e43c6cebc7214fdf1d00dec86de2779c44/third_party/WebKit/Tools/Scripts/webkitpy/tool/commands/rebaseline_cl.py
[modify] https://crrev.com/0c65f8e43c6cebc7214fdf1d00dec86de2779c44/third_party/WebKit/Tools/Scripts/webkitpy/tool/commands/rebaseline_cl_unittest.py