Passing to Aviv for prioritization and assignment. Realistically, this seems like an OKR for next quarter.

> In email, we decided that it would be sufficient to have a build status string that enables the same behavior on all builders. NOPREBUILTS or something.

This makes the build less deterministic (e.g. you launch the same job with the same source code at different times, and get different results). So far all of our tree-status interactions are confined to the master (or a few other monitoring services) but otherwise slave jobs are (mostly) deterministic. Not a fan of this option.

> A better plan would be to have a value checked into the tree that causes prebuilts to be ignored until after they are regenerated (less error prone).

That's in essence what we have already, minus the automatic un-ignoring part. This sounds like a refinement that shouldn't be too major a project. Makes sense to me.

> Best would be to detect that old prebuilts are invalid and refuse to use them (based on the version of toolchain, etc?).

Harder to scope this, don't see it provides much value beyond the above option.

passing the buck

Greg is working on a change that will correctly rebuild all reverse deps when something lower in the deptree changes. So, this might help with some cases. If you landed a core library change, pretty much the entire tree would rebuild on an incremental builder.

OTOH, some things from outside of the board build root are not properly in the depgraph so that improvement might not catch all cases.

Can we have a manually bumped version number that everything implicitly depends on? Then just bump that version to force a full rebuild?

Yea, that might work. 

that sounds good.