instead of a dedicated recipe can we just have a generic recipe that loads its instructions from a script on the repo?

I would like us to stop using recipes, they're a huge pain to maintain, they're not discoverable, they can't be synced with changes in the repo, they can't easily be reverted by the gardener, they don't get managed by the same ACLs as the rest of the project, etc etc etc.

A new recipe for this functionality is actually a good tradeoff, trying to force this use case into the generic flutter recipe complicates the other 99% use cases with a bunch of if-else that are only relevant to coverage. Even worse trying to force this into the generic recipe will require to get back service account authentication that we are actively working to replace with short lived tokens.

I strongly disagree with this (and I wish this handed landed when I had an outstanding comment on the review).

I'm not saying to force this into the "generic flutter recipe", I'm saying we shouldn't even have a "generic flutter recipe", we should just have a single recipe which does nothing but fetch a script from the repo (different script for different shards, e.g. driven from the shard name or something) and run that. I'm saying literally every shard that runs in LUCI on every single one of our repos should all be driven by the same trivial recipe.

The trade-off IMHO is very bad. Like I say above, recipes are hard to maintain, they're not discoverable, they can't be synced with changes in the repo, they can't easily be reverted by the gardener, they don't get managed by the same ACLs as the rest of the project, etc. These are all very serious issues, and we keep making it worse by adding more recipes.

Sorry about landing, I wasn't sure you were going to reply back and I really wanted to address the coverage issue that has been opened for a few years(#81803). If you strongly disagree with this PR I can revert it and let someone else to take over the bug.

I disagree that adding a recipe is worse than having multiple bash scripts or dart scripts running shell commands. In this case the recipe is running a single command flutter test coverage I could certainly have added that command in bash script, call it from the current recipe and then adding 20 more lines in an if - then - else to download a service account from cloud kms and use it to upload the coverage file to GCS. All of this embracing the extra work of encrypting the key, regenerating the key every 6 weeks and weakening the security of our release artifacts bucket.

In terms maintenance the recipe for the flutter repository got its last major update in 08/2021 with small cleanup updates every few months. I wonder how many people are actually touching recipes apart from infra to implement new features or move more logic to the repositories under test.

For discoverability we always use https://cs.opensource.google/flutter, reverting recipe changes is as easy as reverting from any other repository and I'm not sure what you mean by different ACLs but I'll guess this is a GoB vs GitHub discussion rather than a recipes discussion.

Certainly recipes is not dart but recipes along with LUCI is what has allowed us to get to the current state of scalability and resilience that wouldn't have been possible with any of the of external CI systems.