Right now, newtab/messaging unit tests kicked off automatically in Phabricator typically don't run for at least an hour, depending on the queue load. This is very high latency just to get some analysis info on a patch you've uploaded, and slows down what could otherwise be a reasonably tight feedback loop.

The vast majority of the time is because we're using requires-build: true, which chooses to seems to pick a shippable /pgo build, which taskes a very long time to build. I can imagine several ways to one could make this a lot better:

• add an option to pick a regular optimized build rather than a PGO build
• add an option to pick an artifact build (not quite as reliable because it doesn't capture the exact tree pushed to)

We (User Journey) has realized this is blocking some work that we'd like to do soon. :ahal, what would it take to do a minimal solution here (eg pick an optimized build rather than a PGO build)?

The build it uses is entirely dependent on the platform specified in the task's config. The platform to build task mappings are defined here:
https://searchfox.org/mozilla-central/source/taskcluster/ci/source-test/kind.yml#44

So you could create a new entry there that maps whatever "platform" name you want to your desired build, then switch your task to use it.

I don't think there is any precedent for a test task explicitly requesting artifact builds (would we run two builds of the same platform, one with and one without)? But if you want to go that route I guess we could figure something out.. just don't expect a quick fix.

After watching autoland build speeds for a bit, I think we want to use build-linux64/opt, as these seem to turn around the fastest.

(In reply to Dan Mosedale (:dmose, :dmosedale) from comment #0)

• add an option to pick an artifact build (not quite as reliable because it doesn't capture the exact tree pushed to)

Does this really matter ("exact tree pushed")? I believe developers are using just any Firefox installed on their machine when testing locally as karma just needs a Firefox instance. There could be some nightly breakage in the js api that prevents karma from running correctly, but pretty sure we don't depend on specially exposed apis.

No, I don't think the exact tree pushed is likely to cause problems any interesting amount of the time.