what is board name? please provide more info in bug reports

This was follow up from a previously discussion that went to the wrong component, sorry about that.

Like Don mentioned in the design doc, currently each build has a "boards" config, and the value is a list of boards (for most builds, there's only one board in the list).

For example:
    "cyan-paladin": {
        "boards": [
            "cyan"
        ]
    }

So what kind of format you need in the tag? "boards:cyan" or "boards:[cyan]".
What if there're multiple boards? "boards:A,B,C" or "boards:[A,B,C]". 'A', 'B', 'C' should be alphabetically sorted? 

However, we have (or will have) some cases where it's really hard to read the build config when creating the buildbucket request.

This will be especially true when scheduling builds on branches, or from non-ChromeOS specific scheduling tools.

leecy@/jinjingl@, what's your thoughts (given comment#3 and comment#5) ?

"boards: ['A','B','C']" works the best. They don't need to be sorted. 

We will mainly use the tags to query for builds, e.g builds in a certain bucket with boards 'C', 'A', 'M'.   Will querying by tag "boards: ['C', 'A', 'M']" return the right results in this case? 

As for comment #5, @leecy can add to it. I think we don't currently worry about this case ?   

Re: c#5 Sorry can you be more specific about "scheduling builds on branches" -- do you mean the firmware/factory waterfalls, or the release waterfall?  I think that would be problematic.

I'm not sure what non-ChromeOS specific scheduling tools means either?  We primarily want to do this so we can filter the results we get by board.

I'm actually not sure how tag searching works, jinjingl@ can you verify that the boards could be filtered by tag this way if it's  a list, vs. if it's board:A board:B etc.?

Comment #7 might be ambiguous, I meant to query for builds in a bucket who have 'C', 'A' or'M' as their board. 

Actually, we need to issue a separate query for builds for each board tag we want to filter on. It would be best to have the board tags being separated, i.e "board: 'A'", "board: 'B'" as two separate tags for a build. Is this possible ? 

I doubt whether #7 can work correctly. Say a build as three board 'A', 'B' and 'C', then we add the tag "board=['A', 'B','C']", I think we can only get the build if we filter with tag: "board=['A', 'B','C']". "board='A'", or "board='B'" or other kinds of tags can't work correctly.

It sounds to me like we need multiple board tags, like board:A and board:B

Yes, we should do separate board tags if repetitive tag key is allowed. 

dgarrett@ has concerns about this feature. dgarrett@ can you elaborate your concerns and I can put the CL aside for now?

This will work reliably for slave builds, but not for many other types of builders that don't have a master, such as tryjobs, incremental, full, firmware, factory, etc.

I don't think we can reliably populate this information in those cases, so.... should we come up with another solution that is reliable instead?

Yes, if it is possible. Otherwise for these waterfalls we would get all the builds and do the filtering on our side (which potentially would be slower?) 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/chromite/+/7e030c6a1fa44454f6675aba9499d012ef6327c9

commit 7e030c6a1fa44454f6675aba9499d012ef6327c9
Author: Ningning Xia <nxia@chromium.org>
Date: Thu Mar 30 03:48:33 2017

Add board tags in the buildbucket PUT requests for slave builds.

The board tags will be used to search builds with specific board names.

BUG= chromium:700205 
TEST=unit_tests

Change-Id: If7c9095ce12b9fedf8f269518991b3bf3f2f2ae3
Reviewed-on: https://chromium-review.googlesource.com/461200
Commit-Ready: Ningning Xia <nxia@chromium.org>
Tested-by: Ningning Xia <nxia@chromium.org>
Reviewed-by: Don Garrett <dgarrett@chromium.org>

[modify] https://crrev.com/7e030c6a1fa44454f6675aba9499d012ef6327c9/cbuildbot/stages/scheduler_stages.py
[modify] https://crrev.com/7e030c6a1fa44454f6675aba9499d012ef6327c9/cbuildbot/stages/scheduler_stages_unittest.py