Issue 755353  has been merged into this issue.

models is already factored into config_dump (option 2):

https://chromium-review.googlesource.com/c/611007/5/cbuildbot/config_dump.json

it's only used for unified builds though; the logic simply says if models are in the config, use them, else use the board (as previous).  This supports both uni and non-uni configs.

the design is at: go/cros-unibuild-hw-test

can you make comments there and I'll set up some time to review concerns

The ddoc does not seem like the right place for discussion of this implementation detail.

models is separated into it's own section of a chromeos_config entry, but the logic for mapping that and determining which hwtest stages will be created is at cbuildbot run time. That is what I don't like, because it makes it difficult to write unit tests about chromeos_config, or to reason about expected behavior simply from looking at the config. Ideally, I'd like a 1:1 mapping from hw_tests entries to actual hwtest stages.


To put it another way, I do not believe the following code should run at cbuildbot run time (simple_builders.py):

    models = [config_lib.ModelTestConfig(board)]

    if builder_run.config.models:
      models = builder_run.config.models

    for suite_config in builder_run.config.hw_tests:
      # Even for blocking stages, all models can still be run in parallel since
      # it will still block the next stage from executing.
      for model in models:
        new_stage = self._GetHWTestStage(
            builder_run, board, model, suite_config)
        if new_stage:
          parallel_stages.append(new_stage)


Instead, it should be something like:

    for suite_config in builder_run.config.hw_tests:
        new_stage = self._GetHWTestStage(
            builder_run, suite_config.board, suite_config.model, suite_config)
        if new_stage:
          parallel_stages.append(new_stage)

this will be addressed by a longer term task of decoupling the test plan from cbuildbot