Chromium OS‎ > ‎Testing Home‎ > ‎

Intro to autotest_quickmerge

TL;DR: autotest_quickmerge is a fast shortcut for emerge which works for python-only changes to autotest test and control files.

An example

Consider the steps involved in iterating on a python test or control file for a test that uses pyauto, and running the new test on your DUT. Starting with a fresh chroot:

user@host:~/chromiumos/src$ ./setup_board --board=lumpy # optional

user@host:~/chromiumos/src$ ./build_packages --board=lumpy

user@host:~/chromiumos/src$ cros_workon --board=lumpy start autotest-chrome

Make some edits to a test that has dependencies, for instance login_CryptohomeMounted. Now, try to run the modified test...

Option 1: Run test from the source tree.

user@host:~/chromiumos/src$ --board=lumpy --remote=<dut ip> login_CryptohomeMounted

Will not work. Fails with a PackageInstallError. detects, via cros_workon, that it should run from source tree. But the test depends on pyauto and pyauto does not exist in the source tree, so the test fails.

Option 2: Run test from the sysroot.

user@host:~/chromiumos/src$ --board=lumpy --use_emerged --remote=<dut ip> login_CryptohomeMounted

Will not use your changes. The test will run, but it will be the version installed in /build/lumpy/usr/local/autotest/... which doesn’t contain your edits, since they have not be emerged.

Option 3: Emerge your changes, then run test from the sysroot.

user@host:~/chromiumos/src$ ./build_packages --board=lumpy

user@host:~/chromiumos/src$ --use_emerged --remote=<dut ip> login_CryptohomeMounted

Works, but slowly. The build_packages step takes about 2 minutes, even when the only change was to a python file that isn’t compiled. This can be painful if you’re trying to iterate on a test that you’re working on.

Note: a basically equivalent alternative to build_packages here is emerge-lumpy autotest-chrome.

New Option 4: Quickmerge your changes, then run test from the sysroot.

user@host:~/chromiumos/src$ autotest_quickmerge --board=lumpy

user@host:~/chromiumos/src$ --use_emerged --remote=<dut ip> login_CryptohomeMounted

Works quickly. The autotest_quickmerge step takes 2 seconds or less.

What is autotest_quickmerge doing, in detail?

  1. Use rsync to copy newer-timestamped files, and new files, from autotest source tree to the board sysroot autotest tree. Include only specific subdirectories of the source tree, and exclude .pyc files.

  2. For files newly created in the board sysroot autotest tree, assign ownership of these files to the autotest-tests portage package.

  3. Change the version number of installed autotest portage packages to version 0, so that any future runs of build_packages will consider the autotest packages to be out of date, and re-emerge them freshly.

  4. For tests that have been modified, remove the corresponding pre-packaged autotest bzips as they contain stale python code.

How can I rollback changes made by to the board sysroot by autotest_quickmerge?

Simply run build_packages.

When can I use this?

If you have made changes to, or added new, python test files or control files in the .../src/third_party/autotest/files/ tree, and want to quickly test those changes. This includes tests from the following ebuilds:



When can I not use this?

If you have made changes to .c source files (or other sources that need to be compiled)

If you have made changes to python test files or control files not located in the .../src/third_party/autotest/files/ tree.

If your change involved deleting or renaming files, quickmerge will not delete them in the sysroot.

If you need your board sysroot to be identical to what would be produced by cbuildbot, build_packages, or the normal build process.