Finding regression range in B2G

So there’s a lot of tricks to finding regression ranges in general that is cut down by using hg bisect or git bisect.  The essence is doing a bisect of where the good build is and the bad build is until you get down to one revision/pull etc. difference.  Sometimes a clue/educated guess of what the bug is can help make the number of trials lower.

With B2G there’s some other tricks.  QA usually uses MC builds and inbound builds to help lower the regression range.  The reason why is because the builds are already there.

Having said that it sometimes isn’t enough due to many commits in between builds.

That’s where knowing how to make your own builds and using the bisect tools could help.

1) First you will have to setup your own repo.  You could try updating my VM from a previous post.  Or you can setup your own repo following :

https://developer.mozilla.org/en-US/Firefox_OS/Building_and_installing_Firefox_OS

2) you’ll want to make sure you’re working with the right branch.  ie, if you’re trying to find inbound revision, then you want to be pulling from inbound for gecko:

http://hg.mozilla.org/integration/mozilla-inbound/

you may also have to check :

http://hg.mozilla.org/integration/b2g-inbound/

as b2g-inbound is a branch only for b2g check-ins.

For gaia, you should be on master:

https://github.com/mozilla-b2g/gaia

If you working on a previous branch such as 2.1, be sure to use the matching gecko/gaia

Hash revs are based on the branches, so one branch may not have the same hash code for the same checkin as another branch.

Tip: I have a directory for each that I soft link to.  I reconfigure the directory based on the device version that I’m working for and then repoint the soft links.  In most cases you won’t have to reconfigure most of the other stuff.  gecko/gaia are probably the things that will change the most.  Of course, you’ll want to make sure the rest of the repo is reasonably up to date for the version of the device you are working with.

2) once you setup the repo for the device or whatever, the next step is to find the checkin for the bad build and the good build.  If you pull from Mozilla’s FTP site :

https://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-mozilla-central-flame-kk/

you’ll notice a file called sources.xml  You can do a find for the hash code for gaia and gecko.  If you’re working off of the builds in the ftp site, you’ll find that the gecko/gaia hash codes are actually from the git.mozilla.org repo.

To confuse things even more, git.mozilla.org is a git repo of various other repos including hg, git, + more.

Git inbound can be found : http://git.mozilla.org/?p=integration/gecko-dev.git  ( inbound, b2g-inbound )

Git MC can be found : http://git.mozilla.org/?p=releases/gecko.git

And Gaia can be found : http://git.mozilla.org/?p=releases/gaia.git

So if you want to work off the hash code from the builds, you will want to use these repos.

Note : There is a chance that the git.mozilla.org gets out of sync with hg and some of the other repos.  This is why I mentioned it secondary.

3) For gaia, you can find the bisection without having to deal with the rest of the B2G repo.  you can just go into the gaia directory of the b2g and do a git bisect.

ie. :

1. git checkout <gaia revision>
2. git bisect start <first known bad> <last known good>

3. git log  ( to verify which revision is head )

4. make production ( to build ) and try to reproduce the issue.

5. Mark if it’s a good build or bad build : via

a) git bisect bad
– will state the revision is bad
b) git bisect good
– will state the revision is good; move forward in time.
6) it should move to the next revision, double check with git log, and repeat 4 and 5 until it gives the report of which rev is good and which rev is bad.

Gecko is similar in that you can do :

./build.sh gecko

to build the gecko in the b2g repo.

and you can

./flash.sh gecko

to flash the gecko on your device.

Oh I forgot to mention if you want to figure out if the issue is in gecko or gaia, you can swap the gecko and gaia and check.  ie from the bad build take the gecko and flash w/ the “good” gaia and vice versa.  if the bad gecko + good gaia broke then it’s the gecko.  if it’s the good gecko + bad gaia then it’s gaia.

If you’ve figured out if it’s gecko or gaia that broke the issue (you’ll want to use a close regression range for the swap), you will probably want to use the older gaia when checking for gecko regression range, and the latest gecko if you’re checking for gaia regression range.

Once you have the regressing PR, you can back out via : git revert <commit > -m 1

If you run into issues ( ie if there’s a conflict ), then you will have to resolve it via figuring out which lines need to be removed and kept.

hg has similar commands to git.  See http://www.wikivs.com/wiki/Git_vs_Mercurial for a comparative command list.

Some other tips is, don’t clobber unless you have to.  One of the things that’s safe about releng builds is that they clobber all the time.  So doing comparisons makes for certainty.  The one thing you’ll find building is that it takes time.  If you clobber then it could take 2 hrs to build.  clobber is referring to deleting the objects and out folder : rm -rf obj-dir , rm -rf out

Advertisements

About shizen008

Breaking things and getting in trouble for it since '74. Disclaimer: I am not responsible if I make your head explode reading this blog! The writings here are my own expression and not of any companies. I currently work on being a QA for B2G aka Firefox OS
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s