Closed Bug 1033408 Opened 10 years ago Closed 10 years ago

1.4 branch with perma red in travis

Categories

(Firefox OS Graveyard :: Gaia::System, defect)

defect
Not set
critical

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 864178

People

(Reporter: arcturus, Assigned: timdream)

References

Details

Attachments

(1 file)

I've been trying to land bug 1026474 for several days in branch 1.4, this is a bug just for 1.4, and I did a PR to that branch to check that tests and everything is looking good. Unfortunately I've been seeing an error in the system app, regarding homescreen recovery like this: 1) [system] system/HomescreenWindow homescreen window instance. homescreen is crashed Homescreen is crashed at foreground:rerender right away.: TypeError: this.app.element is null at atc_do_opening (http://system.gaiamobile.org:8080/js/app_transition_controller.js:156:7) at atc_changeTransitionState (http://system.gaiamobile.org:8080/js/app_transition_controller.js:94:7) at requireOpen (http://system.gaiamobile.org:8080/js/app_transition_controller.js:255:5) at aw_open (http://system.gaiamobile.org:8080/js/app_window.js:1405:7) at (anonymous) (http://system.gaiamobile.org:8080/js/homescreen_window.js:142:9) at callTimer (http://system.gaiamobile.org:8080/common/vendor/sinon/sinon.js:3171:21) at tick (http://system.gaiamobile.org:8080/common/vendor/sinon/sinon.js:3116:23) at (anonymous) (http://system.gaiamobile.org:8080/test/unit/homescreen_window_test.js:118:9) at wrapper (http://system.gaiamobile.org:8080/common/test/mocha_generators.js:62:19) at run (http://system.gaiamobile.org:8080/common/vendor/mocha/mocha.js:3709:7) at runTest (http://system.gaiamobile.org:8080/common/vendor/mocha/mocha.js:4087:5) at (anonymous) (http://system.gaiamobile.org:8080/common/vendor/mocha/mocha.js:4133:7) at next (http://system.gaiamobile.org:8080/common/vendor/mocha/mocha.js:4013:1) at (anonymous) (http://system.gaiamobile.org:8080/common/vendor/mocha/mocha.js:4022:7) at next (http://system.gaiamobile.org:8080/common/vendor/mocha/mocha.js:3970:1) at (anonymous) (http://system.gaiamobile.org:8080/common/vendor/mocha/mocha.js:3985:7) at done (http://system.gaiamobile.org:8080/common/vendor/mocha/mocha.js:3700:5) at (anonymous) (http://system.gaiamobile.org:8080/common/vendor/mocha/mocha.js:3712:9) at (anonymous) (http://system.gaiamobile.org:8080/common/test/mocha_generators.js:46:20) at wrapper (http://system.gaiamobile.org:8080/common/test/mocha_generators.js:73:15) at run (http://system.gaiamobile.org:8080/common/vendor/mocha/mocha.js:3709:7) at next (http://system.gaiamobile.org:8080/common/vendor/mocha/mocha.js:3979:5) at (anonymous) (http://system.gaiamobile.org:8080/common/vendor/mocha/mocha.js:3990:5) at (anonymous) (http://system.gaiamobile.org:8080/common/vendor/mocha/mocha.js:4938:28) Checking the bugs that were commited to v1.4 branch I saw some of them that were commited with red travis already so we should try to avoid this as much as possible. Bisecting the problem, just made 1.4 branch unit tests run againts my gaia fork: working ok: https://travis-ci.org/arcturus/gaia/builds/28964170 working ko: https://travis-ci.org/arcturus/gaia/builds/28966191 That's bug 996514, that was fixed 2 months ago, but was uplifted to branch 1.4 the 26th of June (monday past week), and since then we had red travis on gaia for v1.4 Don't want to backout this patch, cause I'm sure is working perfectly, but want to ask people involved what should we do in cases like mine: - Fix unit tests for bug 996514 in v1.4 - Backout bug 996514, and land specific patch for v1.4 - Forget about the red tree and continue landing stuff in v1.4??? (booooooh) Reading the last email from John Ford about Gaia-Try, we should be able to start seeing builds for branch 1.4, but so far we just have travis, and we should keep it green in all our builds.
Flags: needinfo?(timdream)
Flags: needinfo?(ryanvm)
Flags: needinfo?(dscravaglieri)
Flags: needinfo?(anygregor)
I have no opinion on this. Happy to help out where I can after a decision is made, though.
Flags: needinfo?(ryanvm)
Flags: needinfo?(dscravaglieri) → needinfo?
Flags: needinfo?
Flags: needinfo?(jsmith)
I think we should backout. We need a green tree at this point on 1.4 to ensure that we've got a stable 1.4 build during dolphin development.
Flags: needinfo?(jsmith)
Blocks: 996514
If a merge ends up with failing tests we should ping the developer to give them a chance for a quick fix and if this is not possible always back-out. Nobody should even merge on top of a broken tree.
Flags: needinfo?(anygregor)
I guess I am responsible. I will either fix unit test of bug 996514 on v1.4 or do a backout today. I think patch of this bug can be a=testonly so I am not going to seek approval and blocking.
Assignee: nobody → timdream
Status: NEW → ASSIGNED
Flags: needinfo?(timdream)
BTW thanks Francisco for filing the bug!
So after some digging, I think this test failed because we are running unit tests in their own sandbox in v1.4. I can write a different test for v1.4 in this bug, but I think the best solution here is to uplift bug 864178 to v1.4. This seems to be exactly what Julian want to do in bug 864178 comment 21, 12 hours ago. I will try to pick up his work there before he got up.
Depends on: 864178
I was blocked from working on bug 864178 because test-agent-server on v1.4 always fail on a Mac. I have created a pull request to isolate the interference and we can merge that first if that makes the tree green.
(In reply to Mozilla Shepherd (This account is used for automation and doesn't receive bugmail) from comment #7) > Created attachment 8449945 [details] > mozilla-b2g:v1.4 PR#21321 This patch is invalid -- I didn't stub the right call. (In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #8) > I was blocked from working on bug 864178 because test-agent-server on v1.4 > always fail on a Mac. > > I have created a pull request to isolate the interference and we can merge > that first if that makes the tree green. I make a mistake on my own machine -- I didn't kill the node server in another terminal window. Let's me see if I can work on bug 864178 now.
I think bug 864178 can be uplift to v1.4 at this point so I am will not write any specific fix here. I am duping this bug there instead. REOPEN if disagree.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: