TravisCI doesn't report back to Gerrit. How about we move the check to the post-merge validation. Then we'll still get feedback on Gerrit but we won't slow down merges.

I'm in favor of (1), but if we can't I'd like to propose my idea instead of (2).

It's not actually slowing down *merges* though right? I thought jenkins doesn't run non-voting tests when merging.

Change 131034 had a related patch set uploaded by Hashar:
Migrate mw core hhvm job to postmerge

https://gerrit.wikimedia.org/r/131034

Change 131035 had a related patch set uploaded by Hashar:
Stop mw/core hhvm job in check, do them postmerge

https://gerrit.wikimedia.org/r/131035

Change 131036 had a related patch set uploaded by Hashar:
dashboard: mwcore hhvm jobs

https://gerrit.wikimedia.org/r/131036

Change 131034 merged by jenkins-bot:
Migrate mw core hhvm job to postmerge

https://gerrit.wikimedia.org/r/131034

Change 131035 merged by jenkins-bot:
Stop mw/core hhvm job in check, do them postmerge

https://gerrit.wikimedia.org/r/131035

Change 131036 merged by jenkins-bot:
dashboard: mwcore hhvm jobs

https://gerrit.wikimedia.org/r/131036

The mess of changes above is to stop triggering jobs when a patch is proposed. Instead it is now run for master and REL1_23 branches when a change is merged by Gerrit. That might provide a useful dashboard.

1. Try passing this option to the build: -vEval.Jit=true

That hopefully will speed things up sufficiently.

The script wrapper already has Eval.Jit=true. That has been added by Erik Bernhardson with https://gerrit.wikimedia.org/r/#/c/117226/ . Without Jit the PHPUnit job is just wayyyy too slow.

I believe this bug can be closed whenever we have verified the post merge jobs are triggered properly.

To further speed up the hhvm build, I guess we want some more bugs filled and figure out what additional settings are needed :-)

Example MW core change:

https://gerrit.wikimedia.org/r/#/c/130781/

hhvm not run on commit or merge, but is on post-merge (yay).

Consequently marking as FIXED. Thanks!