Hm, please don't use Rietveld API for tryjob results, use buildbucket instead.
That said, I have to fix git cl to disallow master names without "master." prefix ( issue 637031 ). CQ has already been fixed yesterday. 

"tryserver.chromium.linux" is a full master name, but not full bucket name. A full bucket name is "master.tryserver.chromium.linux"

I think --master should accept master name without "master." prefix. "tryserver.chromium.infra" is a full master name, not to be confused with full bucket name. A full bucket name is "master.tryserver.chromium.infra".

I think we should leave --master for backward compatibility reasons (not prepend "master." prefix) and add -B/--bucket flag that accepts only full bucket name

tandrii, thoughts?

Agree! Copying your mesage to  issue 637031 .

Sounds good -- for clarification: is `git cl` still the preferred tool for triggering try jobs?

i guess it depends. if this is a script that is running on a dev machine, then by using git cl the script will reuse cached credentials

if this runs on a bot, i am not sure what credentials git cl upload will use. in that case it might be cleaner to use a service account (i am not sure git cl supports that), which means you will have to use buildbucket api directly

Makes sense -- for the particular case I'm interested in now, "w3c-test-autoroller", it has Rietveld credentials on the bot itself, stored in a particular place in the filesystem, and that's used when running git cl try (https://cs.chromium.org/chromium/src/third_party/WebKit/Tools/Scripts/webkitpy/w3c/deps_updater.py?l=81).

It also uses these credentials when uploading and committing CLs, which is part of what it's used for.

It sounds like if it were just triggering try jobs, using a buildbucket service account would be cleaner, but not sure if that's the case if it also needs to upload patches and trigger commits.

If you trigger jobs on CLs, then IMO git cl should be the default way. The reason for this is that there are several properties that ideally should be set on all tryjob CLs so that common recipe modules (like gclient and bot_update) can do the right thing for your tryjobs. It's easier to keep this properties set up in 1 place than scattered across many custom service launchers.

Now, if git cl doesn't support service account credentials, that's a bug and should be fixed. 

Rietveld credentials, in the form of refresh tokens[1] are already deployable using puppets to specific machines. So your current way is 100% the right way to do it, so  long as the credentials file isn't manually copied to machine by you.

[1] I think refresh token can be generated for service accounts as well, so no bug in git cl, but i didn't check.

Thanks Andrii, makes sense :-)