Ideally we should test this in both the PFQ and on the chromium builders (i.e. chromeos-amd64-generic-rel and the arm/daisy equivalent).

> Ideally we should test this in both the PFQ and on the
> chromium builders (i.e. chromeos-amd64-generic-rel and the
> arm/daisy equivalent).

That's the idea.  The sanity suite runs just about anywhere
that we run HWTest.

An alternative (possibly better) solution would be some sort of
build/unit test that runs on every builder everywhere.  The tricky
part is that I don't know whether our current build system has the
hooks that make it easy to add such a test.

Well, I guess there are two problems we should solve:

1. Test for file size increases due to chrome changes, including changes to GN args (i.e in chromeos-amd64-generic-rel).

2. Test for board specific file size increases (pfq-informational and pfq).

One challenge, as always, is leaving some breathing room for small increases, while adding instructions in the test expectations for significant size increases (i.e. how to propose increasing the partition size to support the size increase).

Could this be an image test (i.e. src/scripts/build_library/test_image_content.sh)?

> Could this be an image test (i.e. src/scripts/build_library/test_image_content.sh)?

Aha!  That might be just the ticket.  It looks like failing there would
actually force build_packages to fail, which would mean developers testing
changes would have a good chance to discover the problem before it hits
the CQ.  And failing to produce an image seems useful.

The one drawback is that it means that the buffer between "100% full" and
"too full to ignore" becomes less useful.  Once we get close to the limit,
any change that pushes the size over will suddenly be impossible (or at
least, hard) to build, let alone test.