RossBurton at 15:40, 14 July 2016

2016-07-14T15:40:46Z

← Older revision		Revision as of 15:40, 14 July 2016
Line 1:		Line 1:
	* git bisect run sh -c "cd build ~~; wipe-sysroot~~ ; bitbake $*"		= Using Git to bisect a build problem =
	* git bisect run sh -c "cd build ~~&& wipe-sysroot~~ && bitbake python -C unpack && ~~bb contents~~ python \|grep python-zlib"
			If you have a regression in your build, for example "master" builds fine but your feature branch "devel" is broken in some way, then you can use git bisect to identify the commit which introduced the problem.

			'git bisect' in it's most basic form can be used to help you identify which commit is broken by keeping track of known good and known bad commits, and automatically checking out the commit between the two so it can be tested. When the problem is a broken build or something which can be examined without user interaction then git bisect can automate both the search and test.

			For example, if at some point between master and devel your recipe foo stopped building, then you could drive the bisection like this:

			$ git bisect start
			$ git bisect good master
			$ git bisect bad devel
			$ git bisect run sh -c "cd build ; bitbake foo"

			"git bisect start" says that you want to start a bisection run.

			"git bisect good master" says that master is known to be good.

			"git bisect bad devel" says that master is known to be bad.

			"git bisect run ..." tells git bisect to run the script to determine if the commit it is testing is good or bad, and automatically proceed to the next commit or finish depending on the exit code. For this we need to cd into build (as git bisect needs to run at the top level) and bitbake foo. If the build is successful then the script exits with success and the commit is marked as good, if the build fails then the commit is marked as bad. Either way the bisection the continues, a new commit is selected, and the script ran again until the problematic commit is identified.

			The test script can be as complicated as required. I was debugging a problem where python was no longer shipping the zlib module, so I used this command:

			$ git bisect run sh -c "cd build && bitbake python -C unpack && oe-pkgdata-util list-pkg-files -p python \| grep python-zlib"

			This meant that for every iteration python was forcibly built (python -C unpack says to build python and forcibly run unpack, so it always does a clean build) and then oe-pkgdata-util used to list the packages that python generated, which was then grepped for python-zlib. The final grep provided the exit code, so if python-zlib was present then the commit was good and if it was missing then the commit was bad.

RossBurton: Created page with "* git bisect run sh -c "cd build ; wipe-sysroot ; bitbake $" git bisect run sh -c "cd build && wipe-sysroot && bitbake python -C unpack && bb contents python |grep python-z..."

2016-07-14T13:53:53Z

Created page with "* git bisect run sh -c "cd build ; wipe-sysroot ; bitbake $*" * git bisect run sh -c "cd build && wipe-sysroot && bitbake python -C unpack && bb contents python |grep python-z..."

New page

* git bisect run sh -c "cd build ; wipe-sysroot ; bitbake $*"
* git bisect run sh -c "cd build && wipe-sysroot && bitbake python -C unpack && bb contents python |grep python-zlib"

TipsAndTricks/GitBisectABitbake - Revision history

RossBurton at 15:40, 14 July 2016

RossBurton: Created page with "* git bisect run sh -c "cd build ; wipe-sysroot ; bitbake $*" * git bisect run sh -c "cd build && wipe-sysroot && bitbake python -C unpack && bb contents python |grep python-z..."

RossBurton: Created page with "* git bisect run sh -c "cd build ; wipe-sysroot ; bitbake $" git bisect run sh -c "cd build && wipe-sysroot && bitbake python -C unpack && bb contents python |grep python-z..."