51b2f1b64c
Remove #defines that lived in gn_to_bp.py and android_framework_defines.gni. These have been moved into a new file in Android, SkUserConfigManual.h, in https://googleplex-android-review.git.corp.google.com/#/c/2519600/ Update gn_to_bp.py to include SkUserConfigManual.h, so it will still result in using the same #defines. Lately, we've found it difficult to guard changes behind a flag. e.g. a change to drawing causes a CTS failure in Android, so we have to do the following: - put the change behind a flag, and add it to gn_to_bp.py or android_framework_defines.gni - generate new images on Android (by running CTS with external/skia modified to not define the flag) - create a CL in CTS that uses the new images - land a CL in Skia that stops defining the flag - when the Skia change lands, wait for the auto-roller to create a CL that includes the change, stop the auto-roller, add the topic to the CTS CL so the two can land at the same time - land both Android changes (with TreeHugger) - restart the Android auto-roller With SkUserConfigManual.h (which lives in Android), the process will be similar to Chromium: - land a CL in Android's external/skia that defines a flag e.g. SK_SUPPORT_LEGACY_FEATURE. Land without TreeHugger because it isn't used in Skia and does not do anything - land a change in Skia that changes behavior unless SK_SUPPORT_LEGACY_FEATURE is defined. This will safely go through the Android roll and not change any behavior for Android - create two Android CLs - one in CTS to use the new images, and one in external/skia to delete SK_SUPPORT_LEGACY_FEATURE. Set them to the same topic and land them with TreeHugger In the new process, there is no need to mess with the Android roll. A downside to the new process is that we cannot test the android framework defines without checking in to Android. But given how much we've progressed in automating Android testing, this is fine. Bug: b/63429612 Change-Id: Idfbaef2f4cae641a75fb6e7bf70428733a441336 Reviewed-on: https://skia-review.googlesource.com/22072 Commit-Queue: Leon Scroggins <scroggo@google.com> Reviewed-by: Eric Boren <borenet@google.com> |
||
|---|---|---|
| .. | ||
| builder_name_schema | ||
| core | ||
| ct | ||
| env | ||
| flavor | ||
| git | ||
| infra | ||
| isolate | ||
| run | ||
| skia_swarming | ||
| swarming | ||
| swarming_client | ||
| vars | ||
| README.md | ||
Skia Recipe Modules
This directory contains recipe modules designed to be used by recipes (see infra/bots/recipes). They are all Skia-specific and some are interrelated:
- builder_name_schema - Helps to derive expected behavior from task (formerly builder) names.
- core - Use as a starting point for most recipes: runs setup and sync steps.
- ct - Shared Cluster Telemetry utilities.
- flavor - Allows the caller to specify a high-level command to run, leaving the platform-specific details to be handled by the specific flavor module.
- infra - Shared infrastructure-related utilities.
- run - Utilities for running commands.
- swarming - Utilities for running Swarming tasks.
- vars - Common global variables used by Skia recipes/modules.
When you change a recipe module, you generally need to re-train the simulation test:
$ python infra/bots/recipes.py test run --train
Or:
$ cd infra/bots; make train
Each recipe module contains a few files:
- api.py - This is the meat of the module.
- __init__.py - Contains a single DEPS variable, indicating the other recipe modules on which this module depends.
- example.py - Optional, this file contains examples which demonstrate how to use the module and should contain enough tests to achieve 100% coverage for the module. The tests are run using the recipes test command above.