1046104 - Give the B2G devices in automation a chance to recharge between builds

Status: RESOLVED WORKSFORME

(Testing :: General, defect)

Description

[Dave Hunt [:davehunt] [he/him] ⌚BST]

We've seen a number of times that devices become unavailable via ADB, but when someone's gone to investigate they're found to be perfectly fine. One guess is that the long running performance tests running over and over again on devices is slowly draining the batteries despite the devices being attached over USB.

Comment 1

[Dave Hunt [:davehunt] [he/him] ⌚BST]

Bob: I recall you saying that you'd seen something similar. Could you provide some thoughts on how we might determine if this is the case, and if so, what might be a suitable solution? In Jenkins we can add a quiet period, which means a job will wait a specified number of seconds before starting. If this is before the target device is selected though it may not make a difference, but we could also add a sleep to the individual jobs. It would be best to do this only if the battery is lower than a certain threshold.

Comment 2

[Bob Clary [:bc] (inactive)]

On my flame, /sys/class/power_supply/battery/capacity appears to contain the percentage charge of the battery.

I pause the autophone devices when they fall below a minimum threshold until they reach a maximum threshold. I'm currently using 90-95% for the range. When we get mozpool integrated we might be able to make the charge status a criteria for selecting a device, but until then we might be able to create a new step in a job that checks the battery and sleeps for a period. In autophone's case, it can take an hour to recharge from 89% to 95%.

I have found that when an autophone device has many pending jobs so that there is no wait between them for an extended period of time, a few of the devices will drain quickly but if the jobs are not too frequent, the charging between jobs is sufficient to keep the battery from dropping below the threshold.

Perhaps a combination of guaranteeing a minimum period between jobs and a check on the battery charge to prevent a job from running if the battery is too low would be a sufficient near term strategy.

Comment 3

[Dave Hunt [:davehunt] [he/him] ⌚BST]

Thanks Bob, for now I've started outputting the contents of /sys/class/power_supply/battery/capacity whenever we flash. This will help to determine if the battery level is the cause of our issue. If it is, then I think we'll do something similar and wait for a minimum capacity before proceeding with the flash. Having this built into mozpool would be awesome.

Comment 4

[Dave Hunt [:davehunt] [he/him] ⌚BST]

I don't think we've seen anything recently that confirms this issue, so marking as resolved.