If it is creating a sticky ebuild, it does not seem to be doing a great job, FWIW if we don't manually create a sticky ebuild the branch PFQ does not really function, and it complains there is no sticky ebuild. I would dig up logs but it looks like LUCI does not keep them around long enough :-/, but IIRC we get a failure like https://ci.chromium.org/p/chromeos/builders/luci.chromeos.general/Prod/b8928009604763761376 in syncchrome.

...
Traceback (most recent call last):
  File "../../chromite/bin/cros_mark_chrome_as_stable", line 169, in <module>
    DoMain()
  File "../../chromite/bin/cros_mark_chrome_as_stable", line 165, in DoMain
    commandline.ScriptWrapperMain(FindTarget)
  File "/mnt/host/source/chromite/lib/commandline.py", line 912, in ScriptWrapperMain
    ret = target(argv[1:])
  File "/mnt/host/source/chromite/scripts/cros_mark_chrome_as_stable.py", line 480, in main
    sticky_ebuild = _GetStickyEBuild(stable_ebuilds)
  File "/mnt/host/source/chromite/scripts/cros_mark_chrome_as_stable.py", line 187, in _GetStickyEBuild
    raise Exception('No sticky ebuilds found')
Exception: No sticky ebuilds found
...

I think it should be feasible for the uprev logic to know what we want to do and handle the sticky ebuild though, the main edge case would be if the ToT Chrome PFQ had not passed in time, and the branch was cut with a different Chrome revision we would need to manually uprev, so we often need to make a CL in there anyway.

i'm not suggesting it create a sticky ebuild, but that it not need one in the first place.  it might require some changes to the stable script.

i'm interested in what requirements the TPM side has wrt sticky ebuilds.  on a branch, when would you ever do something other than stick it to e.g. "40.0.2214.x" ?

when i looked through the uprev script, it's making queries to some API end points to get version numbers for the branch ...

I think all we need to do is be able to specify what upstream Chrome branch we try to find new Chrome versions from, kind of like how we have a constant in Chromite to define the upstream Android branch we pull ARC++ container images from (e.g. ANDROID_NYC_BUILD_BRANCH and ANDROID_PI_BUILD_BRANCH). 

If the branch or builder scripts can automatically locate what the associated Chrome release branch is, that would be great. A heuristic like the highest build revision on the current milestone might do it in most cases (only the release branch is likely to go higher than .5 or so, and I am not sure if we are guaranteed to get the right one if we say the highest branch version for the milestone), though this is not perfect, so we would probably want to pull from some Chrome side source, or just set it manually.