Agreed.

I spent some time on Friday trying to get the LUCI presubmit tests running for luci-scheduler.cfg as part of the chromite unittests (which would have prevented this), but was having trouble getting them to run.

Also from Nodir:

"""forgot to mention that the robot might also want to call
https://apis-explorer.appspot.com/apis-explorer/?base=https://luci-config.appspot.com/_ah/api#p/config/v1/config.reimport
to explicitly tell luci-notify to load the latest commit right after it is made. Otherwise luci-config may take up to 10min to notice the change.
we'd need to add the robot service account to https://chrome-infra-auth.appspot.com/auth/groups/config-reimport

after that, ideally the robot would call
https://apis-explorer.appspot.com/apis-explorer/?base=https://luci-config.appspot.com/_ah/api#p/config/v1/config.get_config_sets?config_set=projects%252Fchromeos&include_last_import_attempt=true&_h=2&
to ensure that the revision was accepted. Note that response would also contain validation errors if revision was not accepted (should not be the case since the robot called validation API before making the change).

RPC definition, in python unfortunately
https://cs.chromium.org/chromium/infra/luci/appengine/config_service/api.py?q=config_service/api&sq=package:chromium&g=0&l=230
"""

What are the required arguments to config.validate_config, and config.reimport?

I'm sure they are documented somewhere, but I don't see where yet.

they are not well documented. This is cloud endpoints (as opposed to prpc), so one has to read python code :( I am sorry about that

reimport: https://cs.chromium.org/chromium/infra/luci/appengine/config_service/api.py?q=config_service/api&sq=package:chromium&g=0&l=460&rcl=9bac6d2446f6d1a8d5db6bfcb32804b52d04ea06
validate_config: https://cs.chromium.org/chromium/infra/luci/appengine/config_service/api.py?q=config_service/api&sq=package:chromium&g=0&rcl=9bac6d2446f6d1a8d5db6bfcb32804b52d04ea06&l=160

is this robot making commits to
https://chrome-internal.googlesource.com/chromeos/manifest-internal/+/infra/config
a temporary solution?

It seems to be mutually exclusive with the go/luci-config-push effort which assumes that configs will be pushed by Chrome Infra Auth service.

With the high-level config effort, we are moving towards one config file that configures all of LUCI (as opposed to per-service config, e.g. cr-buildbucket.cfg, luci-scheduler.cfg). What system will generate that config file, with all buckets, builders, scheduler jobs, etc? Would Chrome Infra Auth Service know all of this? I don't know much about Chrome Infra Auth service, but it seems to be a scope creep.

If this robot can make commits to the repo, why do we need go/luci-config-push? Why can't it load partner projects from Chrome Infra Auth, add other LUCI concepts (builders, scheduler jobs) on top and make a commit?

we need a mailing list for these discussions

I created the bot as a way to reduce management overhead for myself, TPMs, and others adjusting our builds schedules until go/luci-config-push is ready.