Different chromeos repositories have different testing needs. Using per-repo or per-directory configuration files, it is possible to tailor the behavior of the Chromeos Commit Queue to suit the particular change being tested.
Per-repo and per-directory configuration
Each repository may optionally contain a COMMIT-QUEUE.ini located in the root directory of the repository, formatted as described below. In addition, sub-directories of the repository may contain their own COMMIT-QUEUE.ini files.
When examining a change, the Commit Queue will look at the files that are modified by the change, and will look for a config file for their common parent directory. If no config file is found in that directory, it will continue up the directory tree until it finds one. Note that this means the the configs for subdirectories will fully override those for parent directories.
Specifying build targets to test with in the pre-CQ
Some repositories or subdirectories (e.g. board specific overlays) contain code that only affects a particular board or small set of boards. These repos can use be tested in the pre-cq using a targeted set of build configs, rather than the default set. This behavior is configured with COMMIT-QUEUE.ini as below.
In this example, the pre-cq would test changes to this repo by launching lumpy-pre-cq and stumpy-pre-cq tryjobs in parallel. Note, configs that are specified in this list must have their config attribute pre_cq = True in order to work. Once this config option is specified, it will take effect in the pre-cq after the pre-cq-launcher is restarted.
Submit changes in the Pre-CQ
If a particular repository is not used by any builders in the CQ, then the CQ doesn't add any value and it is safe to skip the CQ and submit changes in the Pre-CQ. You can set this up by adding the following to your COMMIT-QUEUE.ini file.
Ignoring certain failures
Some repositories (e.g. firmware repositories) contain code that is very unlikely to break hardware or VM tests. When these tests fail, CLs in these repositories would normally be rejected unfairly. To prevent this, it is possible to configure what tests stages should be ignored in a
In the case where the
Currently, the following stages can be ignored: