tree: bfb45617a1263f1e8f40155b5c692f0f9714b17d [path history] [tgz]
  3. bugdroid/
  4. chrome_infra_packages/
  5. chrome_infra_stats/
  6. chromium_bugs/
  7. chromium_build/
  8. chromium_build_logs/
  9. chromium_build_stats/
  10. chromium_committers/
  11. chromium_cq_status/
  12. chromium_rietveld/
  13. chromium_status/
  14. chromium_try_flakes/
  15. cr-buildbucket/
  16. cr_rev/
  17. experimental/
  18. findit/
  19. monorail-predict/
  20. monorail/
  21. test_results/
  22. third_party/
  23. ts_mon_test/


This directory contains appengine applications, one per subdirectory (the testing framework relies on this assumption to list all tests). To be consistent with appengine principles, each of these directories must contain everything it needs to work. Code shared between several applications should live in appengine_modules/ and be symlinked into each application directory that needs it.

Creating an appengine application


Create a new Appengine app by running <app_name>.

The script will create a minimal structure of a working Appengine app in infra.git:

  • an app directory under appengine/, say appengine/myapp
  • appengine/myapp/app.yaml
  • appengine/myapp/ implements a trivial public endpoint.
  • appengine/myapp/ is a symlink pointing at appengine_modules/ This is required for testing, see below.
  • appengine/myapp/.expect_tests.cfg lists any third-party components that should be skipped by tests.
  • appengine/myapp/components (optional) points at luci/appengine/components/components. Most infra apps require authentication, and components/auth is our standard. Delete this link if your app does not use it, and edit .expect_tests.cfg appropriately.
  • appengine/myapp/ points at luci/appengine/components/tools/ (optional), a handy script for deploying and managing your app.
  • appengine/myapp/test/ (optional, but highly recommended) tests for

Example: the myapp application should live in appengine/myapp. To use appengine_module/testing_utils, create a symlink to it in appengine/myapp/testing_utils. The name should remain the same as Python relies on directory names for its import system.

Note: symbolic links do not work on Managed VMs. A workaround is to create a temporary deployment directory:

rsync -L -r appengine/myapp /tmp/deploy_myapp
pushd /tmp/deploy_myapp/myapp
<deploy your app here>

AppEngine Modules

The default module is configured in app.yaml. Any non-default module must be configured in module-<module_name>.yaml. This is how the script will know you what modules you have.


Tests included in AppEngine applications (classes deriving from unittest.TestCase) are run by Some convenience functions to help using the testbed server are included in appengine_modules/testing_utils. Some examples can be found in existing applications, and a simple test setup is also provided by the script.

See Testing in infra.git for more details. In particular, it's important to have a test file tests/ for every source file

Note: for test code to be able to import modules from the AE SDK (e.g. endpoints), some manipulation of sys.path has to be done by This manipulation has to be performed in an file located at the root of the appengine app, with the content of appengine_module/ Adding a symlink to that file should be enough for 99.99% of cases. (and yes, it's very hacky, we know).

Managing AppEngine apps

A convenience script wrapping called can be used to simplify and normalize the deployment process in infra.git. Just add a symlink to it in your application as It is located in luci/appengine/components/tools/

cd myproject
ln -s ../../../luci/appengine/components/tools/

Run --help to see what can do.