We support per-branch CQ configs. All you need to do is add the branch with cq.cfg in refs.cfg on infra/config branch, e.g. https://chromium.googlesource.com/infra/infra/+/infra/config/refs.cfg. Please make sure that the new cq.cfg has a different CQ name. You can send both the CL adding refs.cfg and branch-specific CQ config to me.

Sergiy, I don't think we do, at least not tested. CQ.cfg in one branch applies to all branches with different caveat in case of Rietveld: notry=true for branches other than where CQ.cfg is configured.
I don't like where we are now, and that's why I made proposal for CQ.cfg living in project config and have sections for different refs. I can't dig up link to it (on phone, and of corp now)

Caveat: I have no idea how the CQ works.

I was able to get this working by adding the long-running branch to refs.cfg on the infra/config branch and adding infra/branch-config/cq.cfg on the branch itself.  I think this only works because the master branch does not have a cq.cfg.

What confuses me is Sergiy's comment, "Please make sure that the new cq.cfg has a different CQ name".  Does that mean, for example, if we have one cq.cfg on a master branch, and we fork a branch from that (thus, cq.cfg is unchanged but now is on a different branch), we will have a conflict?

I'm also unclear on why we need to list the important refs in refs.cfg; can't we just assume that everything under refs/heads/* deserves to be treated as important (eg. can use CQ)?

Yes, it will mean a conflict if you branch the same conflict into a new branch. OTH, if the branch is not listed in refs.cfg, it won't be discovered automatically. I am not sure why we chose to list refs in refs.cfg and not assume all refs/heads/*, but Nodir, who designed the service, may know more.

I support Andrii's proposal to have a project-wide config with a list of branches and this was discussed several times. OTH this requires someone to implement this, while branch-specific configs should be already supported as they are discovered via luci-config and that service does have tests.

I don't remember exactly why we require specifying refs explicitly, but discovering refs automatically would imply much more requests to Gitiles, which means the quota would be exhausted much faster. This is a rare case, so it would be suboptimal to poll all refs when in practice there is only master branch (90% cases)

Branch configs are not supported in CQ in a sense that they are broken. You can have two configs, but both will apply to all branches, in fact all refs. If you try it, and it actually works as intended without races, let me know -- I would love for it to work :)

To be clear, my immediate issue has been resolved, so I'm perfectly happy if we close this bug as-is, though it sounds like there would be a problem if we wanted to have different behavior for different branches on the CQ.

Skia engineers seem more and more interested in making full use of Git features, rather than the single-line commit history we've used in the past.  So I've been trying to make those things happen naturally: add a branch and it gets tested automatically, follow merges correctly, etc.

Why doesn't CQ instance derive its name from the config set? It is unique and doesn't have to be supplied by the user.

This is because CQ name is visible to users on Rietveld as "Project". I don't recall exactly, but I think there was a pushback when we suggested to change "chromium" into "chromium_heads_refs_master".

Why not use project id ("chromium") if it is the master branch?

Hm, cq_name shouldn't be required in config file at all. What should be required is name of the project, and for Rietveld CQs only.

And for CQ process management, the process name (currently, cq_name[__gerrit__]) should be dervived from <luci_config_name>

I think I was wrong in #9. Rietveld has "Target Ref" property and we could have used that. Not sure why we didn't get rid of cq_name altogether yet.

Ok, so we have wasted quite a bit of time between various engineers for patches 
in the infra/config branch. Example: https://webrtc-review.googlesource.com/c/src/+/20221. The CQ will fail to apply any patches in that branch. Is there any way to turn off the CQ in rietveld if we're not on master? That failing, is there a way to add No-Try:true and No-Presubmit:true to the default CL description if we're off the master branch?

+mknyszek who was working on CQ config 2. FWIU his work would solve this issue too. Was that project abandoned? I don't see a bug number in https://chrome-internal.googlesource.com/infra/infra_internal/+/614723941add42edbe1c8d5a04658967f15d2645

So I admit I don't really understand most of the above conversation, but this bit us today: we have a bot on the Skia commit queue which does not work for branches other than master.  It would be nice if we could avoid running it where it is not expected to work, rather than having a project-wide CQ config which only really works for master.

Issue 512076 has been merged into this issue.

Re #17 that for infra/config branches I've hardcoded automatic "No-Try: True" ~2 months ago.

I'm writing yet another design doc for this, taking into account changes into CQ deployment.

in the new design, please fetch configs from project config set, so that we can remove ref config sets

Design doc: https://goto.google.com/cq-for-branches 

Update:
 1. Progress in refactoring existing CQ to make implementing this feature possible, e.g. issue 884935 is almost done.
 2. I'm now working full time on this bug and its blockers.

with 884935 done, are there blockers remaining here? If not, what's left to do?

The full time was a lie :( I shared my time for planning CrOS support in browser CQ.

Nevertheless, I had progress. Finishing up work on 907334, which moves cq.cfg next to cr-buildbucket.cfg and allow to configure different verifier configs for different refs.

I can spend some time on this if you need some work to be done.

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/infra/infra_internal/+/6e4b4369e9bb31ff4a9de43510ea17b3fa6473c6

commit 6e4b4369e9bb31ff4a9de43510ea17b3fa6473c6
Author: Andrii Shyshkalov <tandrii@chromium.org>
Date: Wed Dec 19 04:16:51 2018

Update: while I have all CLs ready for support multiple branches, I had expected production free to start this Friday, not Wednesday (tomorrow, as of this writing). So, I won't deploy this before freeze. Hence, this will be ready in first week of January instead. Sorry for delay.

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/infra/infra_internal/+/74afb8fdb467a04769942d3cfffbd61aecfcaab8

commit 74afb8fdb467a04769942d3cfffbd61aecfcaab8
Author: Andrii Shyshkalov <tandrii@chromium.org>
Date: Fri Jan 04 01:54:31 2019

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/infra/infra_internal/+/b8faca0b2267f9a12a085b7b92b0de2e9f84eae3

commit b8faca0b2267f9a12a085b7b92b0de2e9f84eae3
Author: Andrii Shyshkalov <tandrii@chromium.org>
Date: Fri Jan 04 02:07:21 2019

Given the comments in yesterday's foundation meeting, is this now done? How would a client go about using it?

John, good question. The answer first switch to new cq.cfg[1], then add extra config group matching different ref_regexp. 

In fact, I intend to migrate cq.cfg for chromium myself, martiniss@ has already seen a CL to do so (tracked in issue 916292). But, I've just hit a problem with migration path due to Fuchsia (ab)use of LUCI configs. I'm tracking that issue 920903.

[1] https://cs.chromium.org/chromium/infra/go/src/go.chromium.org/luci/cq/api/config/v2/cq.proto?q=v2+cq.proto&sq=package:chromium&dr&l=43