Looks like the checks are unhappy.

@jonahwilliams - yes it is. I don't know the answer to that question though - @keyonghan or @godofredoc might have thoughts.

question though - @keyonghan or @godofredoc might have thoughts
Ideally we should prefer more tasks with less execution time over less tasks with longer execution times. This will allow us to make more efficient use of resources when we increase the devicelab capacity.

Actually, this adds a test to the Macrobenchmarks application, but I don't think it adds a definition of where to run it. That's changed since I last did this.

@christopherfujino do you know why the test failure https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket.appspot.com/8848843484897376256/+/steps/run_test.dart_for_framework_tests_shard_and_subshard_misc/0/logs/stdout/0#L13293_0 is happening on this patch? IT seems unrelated to me, but rebasing to head doesn't seem to have helped.

The test is now disabled on HEAD (see tree-status chat), so rebasing on master should now fix it.

I've also added this to its own builder. @jonahwilliams to your question, we run the macrobenchmarks app in a bunch of tasks, each isolated to its own test.

The builder configuration needs to be added in flutter/infra first before enabling here in prod_builders.json, otherwise test will not be triggered.

I'll open the infra PR shortly.