Closed Bug 1020050 Opened 11 years ago Closed 11 years ago

[B2G] A check for gaia build size is needed

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: wachen, Assigned: yurenju)

References

Details

Attachments

(2 files)

There has been many times that a build exceed some devices' maximum capability. Especially, devs check in so many pictures, images, or video. In that way, it will not successfully flash the phone. For example, there is a build with 8MB of pictures checked in, and for next few builds, we can't flash gaia of buri due to its size limitations. You can refer on https://bugzilla.mozilla.org/show_bug.cgi?id=1019321 I'd like release engineering team to add a check for each devices about its maximum build size. In that case, we can catch it or figure that out in the very beginning. Or, perhaps we should add a check in gaia travis server for that?
This is a good idea. I think the question we should figure out is where the build failure should be triggered. Tim - Is there anything we can do in build automation on the Gaia side to trigger a test failure if the build exceeds X MB?
Flags: needinfo?(timdream)
Flags: needinfo?(timdream) → needinfo?(yurenju.mozilla)
This is something we should do in build.sh; then we get it for free on every device + local builds.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
I am going to reopen this. First of all, you should look at my description before you close it. Go through it and see what I was saying in the end "Or, perhaps we should add a check in gaia travis server for that?" I was trying to indicate that we should have something to check the size of gaia build. However, you are dup this to a gecko+gonk file size bug. Did you even go through my original bug once? Okay, next thing, didn't you see that there is a needinfo tag for others? Did you see we are trying to reach a conclusion or get a discussion here? Without any discussion or understanding, you close the bug as dup. That is not a good thing. Maybe I open it in a wrong category, but I just want to get a discussion about release process. You can try to change its category, but don't ever close a bug before others are still discussing it. I mean, at least, you can understand it before you close it?
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Adding "gaia" in case people didn't go through the description for at least once.
Summary: [B2G] A check for build size is needed → [B2G] A check for gaia build size is needed
Jason, we can do that in gaia build integraion test, we should test for production build (only with core apps) and engineering build (with a lot of test apps), what size do you think which is resonable?
Assignee: nobody → yurenju.mozilla
Flags: needinfo?(yurenju.mozilla)
Flags: needinfo?(jsmith)
more information -- we got 60MB for engineering build (only |make|) and 41MB for production buid (MOZILLA_OFFICIAL=1 PRODUCTION=1 make)
Component: Release Automation → Gaia::Build
Product: Release Engineering → Firefox OS
QA Contact: bhearsum
Status: REOPENED → ASSIGNED
(In reply to Yuren [:yurenju] from comment #5) > Jason, we can do that in gaia build integraion test, we should test for > production build (only with core apps) and engineering build (with a lot of > test apps), what size do you think which is resonable? Good question. Based on the recent regression that happened in bug 1019321, we know that adding bug 960720's patch & bug 965711's patch caused us to run out of space on Buri. Walter - Can you do some measurements here to find out the exact build size increase by bug 960720 & bug 965711's patches? Also, if I apply one of those patches, but not both, does a Buri eng build fail to flash? Or do I need both patches to cause Buri eng to fail to flash? Context - I'm trying to figure out a good number to give Yuren here to include in the automated test case.
Flags: needinfo?(jsmith) → needinfo?(wachen)
I did figure the size out. It's 8004kb or something as I comment in previous bug. However, I think I heard from Stephen that it's around 4 or 6 MB before we reach our maximum (So, 8004kb is not allowed.)
Flags: needinfo?(wachen) → needinfo?(stephen.donner)
(In reply to Walter Chen[:ypwalter][:wachen] from comment #8) > I did figure the size out. It's 8004kb or something as I comment in previous > bug. However, I think I heard from Stephen that it's around 4 or 6 MB before > we reach our maximum (So, 8004kb is not allowed.) Other than what I saw and asked Dylan to file on in bug 1019321, and the failed-console.log that I'm attaching, I don't know how to answer the question -- I can only go on what I saw output in the console of the at-the-time failing build, sorry.
Flags: needinfo?(stephen.donner)
Attachment #8434632 - Attachment mime type: text/x-log → text/plain
Maybe a good starting point is 65 MB. Does that work for everyone?
Per Jason's suggestion, what about 65MB for buri in the very beginning?
Flags: needinfo?(yurenju.mozilla)
let's use 65MB for beginning.
Flags: needinfo?(yurenju.mozilla)
Status: ASSIGNED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: