I’m actually not sure if we should have that field. It might be a mistake. Why do you need it? Doesn’t CQ table provide that info?

I liked this field and I still do because this provides symmetry between Gerrit patch and Git commit.

I don't mind setting Gerrit project in CQ when triggering builds in CQ, if you tell me how :)

Setting it isn’t supported in v1 today. It’s just there are other schedulers, git-cl-try, apps. I’m thinking if we want to preserve it, then bb should retrieve it from Gerrit, but there is confused deputy problem...

I think it would be great if we have one place to tell both:
1) For the patch being tested, which gerrit project, gerrit change id, and gerrit patchset id it is
2) For the code checkout, which gitiles project, ref, and revision it is

Findit's new flake detection would like to index a flaky test and its occurrences with gitiles project info and gerrit project info respectively so that it could be extended to support other projects besides Chromium.

CC'ing Quinten as we discussed this too in the context of Tricium. While not directly related, I think about something that is coherent everywhere is valuable, the actual detail doesn't matter too much to me.

this will be implemented by clients specifying "project" field when scheduling new build using new ScheduleBuild API. The field will be required in the new API.

this also needed by recipes that need to know the CL project