We tested the V18D-1 base image locally with manual and automated test runs and all the tests passed as expected. Let's update the CI devices to the new V18D-1 base build
I will start working at this task. Dave can you help me with the steps for updating the phones?
Assignee: nobody → florin.strugariu
QA Whiteboard: [fxosqa-auto-s8]
Sure, here's the steps I've used in the past: 1. Upload the base build to /var/tmp on jenkins1.qa.scl3.mozilla.com 2. Create a job to copy the build from /var/tmp and archive it (see flame.v188-1.download as example) 3. Create a job to flash the build (see flash.flame.v188-1 as example) I would recommend taking a device out of the pool for testing first. If it's successful then you can schedule a flash for each of the nodes.
1. Dave helped me with uploading the build to Jenkins. 2. I created 2 new Jobs: 2.1 flame.v18D-1.download http://jenkins1.qa.scl3.mozilla.com/job/flame.v18D-1.download/ 2.2 flash.flame.v18D-1 http://jenkins1.qa.scl3.mozilla.com/job/flash.flame.v18D-1/ 3. Took out b2g-07.1 out of the build pool by removing the "UI" label: http://jenkins1.qa.scl3.mozilla.com/computer/b2g-07.1 4. Ran tests on that node: 4.1 Flash node: http://jenkins1.qa.scl3.mozilla.com/job/flash.flame.v18D-1/2/console 4.2 Show version: http://jenkins1.qa.scl3.mozilla.com/job/show.version/162/console 4.3 Sanity test addhoc: http://jenkins1.qa.scl3.mozilla.com/job/flame-kk.ui.adhoc/592/console All the tests where OK and I think we can proceed with flashing the full grid
Next steps: 1. Flash all the nodes to V18D-1. 2. Add b2g-07.1 back to the build pool.
We've been delaying this due to the lab meltdown caused by bug 1122119. I think it's probably time to go ahead and pull the trigger. Reasons are: 1) The problem persists now on 188, so we're not buying anything aside from limiting variables. 2) Looks like that bug might be base-build agnostic, given the string of repros on different setups. 3) According to catlee, we're mixing in 18D blobs now into the packages, so we're actually in a franken-state after flashing. That might actually be muddying things a bit. Dave, you'd expressed the same concerns I did re: changing things at an unstable time. Given above, are you OK with us making the move? If so, Bebe, think you can proceed, but I think we might want something like a smoketest run to qualify instead of just sanity. If I weren't concerned about melting down mid-run, I'd say run both smokes and non-smokes before moving.
No objections here.
I retested this and updated the nodes to the new base build we still have some nodes that could not be updated to the new base build because of the white screen crash. Nodes not updated: b2g-22.2 b2g-17.2 Geo can you ping me when you restart these nodes
22.2 wasn't crashed but was non-responsive to ADB for some reason. Restarting fixed it. 17.2 looks like it was the very last node to white-screen and not get caught. I could swear they were all responsive this morning, but it was indeed sitting at 100% charge. Sorry for assuming otherwise in the other thread. I brought both back and ran the 18D-1 flash job on them both from Jenkins, so I think we're good. Closing this out.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.