Open Bug 1391130 Opened 3 years ago Updated 1 year ago
Define test harness arguments in the task definition instead of mozharness
This only applies to the 'test' kind. Currently arguments to the harness are defined in mozharness configs, like: https://dxr.mozilla.org/mozilla-central/source/testing/mozharness/configs/unittests/linux_unittest.py#106 Instead, we should define these somewhere in the task definition. This has a few benefits: 1) We can use a morph template to modify the arguments 2) Allows devs to modify harness arguments via create task/edit and retrigger 3) How harness is being run is more transparent 4) Gets us one step closer to moving off of mozharness
Some notes I shared with ahal on IRC: One place to define all configuration is a great win. There might be some config that is *only* applicable to Mozharness and devs won't care. mach commands would have to grab configuration values from task definitions rather than MH configs.
I made some good progress on this, unfortunately hit a road block. There's no good way to pass in test harness args over buildbot-bridge, we'd have to create a new buildbot property. There's no env or extra command line that gets forwarded. I talked to :catlee and he said the migration off of buildbot is mostly blocked on getting new hardware, and could conceivably be done by early Q1. I think it makes more sense to block on the migration than to try and figure this out. That's not to say progress needs to stall out completely. I already have patches that lay all the ground work for this, I think we should still get them landed in the meantime, and maybe convert a suite that doesn't run over buildbot-bridge anywhere (like xpcshell) as a proof of concept.
Assignee: nobody → ahalberstadt
Status: NEW → ASSIGNED
there is not much run on buildbot-bridge these days- this plan sounds good.
Assignee: ahal → nobody
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.