This bot, along w/ ios-device and ios-simulator-xcode-clang, were pulled from the CQ in issue 739556 for capacity reasons.

IIRC, ios-simulator and ios-device build w/ chromium's version of clang, while ios-simulator-xcode-clang and ios-device-xcode-clang build w/ xcode's.

As a sidenote, the specific compilation failure in this case was due to use of std::array with a braced initializer list, which tickled recently-fixed clang bug https://bugs.llvm.org/show_bug.cgi?id=21629 .  Maybe Chromium's version of clang has that fix, while XCode's doesn't?

probably -- i know thakis@ has mentioned that we're closer to clang tot than xcode is.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/df21c2237e036a49218269e5ca1b27e9518646f4

commit df21c2237e036a49218269e5ca1b27e9518646f4
Author: Michael Warres <mpw@chromium.org>
Date: Fri Mar 09 22:08:26 2018

Fix ios-device-xcode-clang compilation error introduced by https://chromium-review.googlesource.com/c/chromium/src/+/956843

The compilation error appears to be due to clang bug
https://bugs.llvm.org/show_bug.cgi?id=21629 , which has been fixed recently,
but apparently has not made it into the clang used by ios-device-xcode-clang.

R=rch@chromium.org

Bug:  820529 
Change-Id: Iaac1d28f2209502c4ce4683b3f590d9140fe3141
Reviewed-on: https://chromium-review.googlesource.com/956299
Reviewed-by: Ryan Hamilton <rch@chromium.org>
Commit-Queue: Michael Warres <mpw@chromium.org>
Cr-Commit-Position: refs/heads/master@{#542244}
[modify] https://crrev.com/df21c2237e036a49218269e5ca1b27e9518646f4/net/quic/core/quic_ietf_framer_test.cc

jbudorick: Thanks for the background!

It looks like  issue 739556 was closed about a year ago. Hs the capacity situation changed at all since there? Is there any chance we could at least enable an xcode build to avoid compile errors like this landing?

#5: it's something we could look at.

+cc huangml, as you've been looking at iOS capacity recently, albeit at the test level rather than build level

The three trybots(ios-device-xcode-clang, ios-device, ios-simulator-xcode-clang) has ~10 builders each.  They're mostly idle as these bots are not on CQ.  For the short term,  we can possibly move around a few builders and it'll be possible to at least put one of them on CQ.

+dpranke because this has come up twice in two weeks.

We're never going to have full CQ coverage for our bots, and in general we're moving in the other direction.  I think we have similar setups for other platforms -- how do we message that not every bot is on the CQ?

This is something that needs to be better documented and communicated, no question.

There's a long list of improvements to infra/ops documentation that I wish I had time to work on. In the meantime, I can at least send a note out to chromium-dev@ so that there's a record *somewhere*.

It is unlikely that we'll ever have 100% CQ coverage, though I wouldn't necessarily agree that we're moving in the other direction, either. We *should* have 100% optional trybot coverage, so that the breakage can be debugged, and we do in this case.

That, this particular bot almost never breaks and I don't think would be a very good candidate for the CQ.

Link to PSA to chromium-dev about this: https://groups.google.com/a/chromium.org/d/msg/chromium-dev/D2jDTlAjCFw/zMDWQJUDCAAJ