Closed Bug 1474897 Opened Last year Closed 6 months ago

Change bitbar testing to use generic-worker instead of taskcluster-worker


(Testing :: General, enhancement, P2)



(firefox68 affected)

Tracking Status
firefox68 --- affected


(Reporter: bc, Assigned: aerickson)




(1 file, 2 obsolete files)

per bug 1405767 comment 11, we will need to switch to generic-worker from taskcluster-worker. I believe I can create a development Docker image @ bitbar to test this change. I'll come up with a list of possible changes that are required shortly.

pmoore, wcosta: If you have any suggestions on how to proceed, I would certainly appreciate it.
Priority: -- → P2

aerickson: assigning to you since you are working on this.

Assignee: bob → aerickson
Duplicate of this bug: 1488392

My initial work on this is at It's definitely a work in progress. The g-w in the docker image starts up and attempts to grab work.

The two largest bits of feedback from bc on the change:

  • We need to modify the payload or figure out how to modify invocation to work.
  • We need to hide secrets that are in envvars from generic-worker (it runs setenv or equivalent and displays it).

:tomprince, how should I differentiate between standard linux g-w and bitbar g-w. In I create a new os (linux-bitbar), but not sure if that's the best/approved way. Thoughts?

Flags: needinfo?(mozilla)

I understand the concern about using a new os, and agree that it isn't ideal. However, I think it is the best existing mechanism for handling this, and that doing something else is probably out of scope.

Flags: needinfo?(mozilla)
Attached file bitbar g-w migration: g5 perf tests (obsolete) —


trigger run on test worker via:

./mach try fuzzy --no-push --artifact --full --query 'android-hw-g5 raptor-speedometer !power'

Attachment #9049379 - Attachment description: switching bitbar test worker to generate g-w payloads → bitbar g-w migration: g5 perf tests
Flags: needinfo?(bob)
Attached file bitbar g-w migration: g5 unit tests (obsolete) —

We'll be roughly following the procedure described in the previous g-w migration for linux workers in Generally, we're going to create new workers and pools, switch central to use the new pools, and finally uplift to other trees once things are stable.

change/PR roundup:

Migration Steps:

  • mozilla-bitbar-devicepool: 1st PR (introduce new workers, add single host to each): land and update autophone1
  • test new queues with final hg patch
  • get final hg patch reviewed
  • setup monitoring for new queues
  • mozilla-bitbar-devicepool: create 2nd PR (moves half devices to new pools), get reviewed
  • mozilla-bitbar-devicepool: land 1st change & update devicepool
  • land final hg patch
  • mozilla-bitbar-devicepool: land 2nd change & update autophone1
  • monitor queues, adjust new/old worker balance if necessary, and troubleshoot
  • uplift final hg change to other repos/trees when things are looking stable
  • merge mozilla-bitbar-docker PR once all tc-w are gone
  • remove leftover taskcluster-worker code in tree
Attachment #9051803 - Attachment is obsolete: true
Attachment #9049379 - Attachment is obsolete: true

I've landed the 1st PR for devicepool and have started testing the new queues/clients.

Flags: needinfo?(bob)
Attachment #9049379 - Attachment is obsolete: false
Attachment #9049379 - Attachment is obsolete: true

Testing is complete. We're going to land the hg tree change today.

Pushed by
switch bitbar workers to g-w r=bc,tomprince
Closed: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68

Keeping this open until all work is done.

Resolution: FIXED → ---
See Also: → 1544945

Things are looking good. We still have the last 3 steps in the migration plan left (

Going to close this now and track remaining work in Bug 1544945.

Closed: 6 months ago6 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.