Lines Matching refs:we
10 1. "bot toggling" - make it so that we can easily flip a given bot
18 we need to wrap both the `gyp_chromium` invocation to generate the
83 * In an ideal (un-resource-constrained) world, we would build and test
85 necessarily mean that we would build 'all' on every patch (see below).
87 * In the real world, however, we do not have an infinite number of machines,
88 and try jobs are not infinitely fast, so we need to balance the desire
90 times, given the number of machines we have.
92 * Also, since we run most try jobs against tip-of-tree Chromium, by
99 targets affected by the patch, so that we don't blame or punish the
104 1. We need a way to indicate which changed files we care about and which
105 we don't (the affected files of a patch).
107 2. We need to know which tests we might potentially want to run, and how
115 nothing about test steps, we have to have some way of mapping back
117 is *not* currently available to MB (or GN or GYP), and so we have to
129 5. However, for some meta targets, we don't necessarily want to rebuild the
137 6. As noted above, in the ideal case we actually have enough resources and
138 things are fast enough that we can afford to build everything affected by a
143 graph, so we will need to write code to handle that specially.
145 7. In some cases, we will not be able to correctly analyze the build graph to
148 In that case we should simply build and run everything.
150 The interaction between 2) and 5) means that we need to treat meta targets
151 two different ways, and so we need to know which targets should be
153 so that we can map them back to the appropriate tests.
155 So, we need three things as input:
159 should be reported back so that we can map them back to the appropriate
161 * `additional_compile_targets`: the list of ninja targets we wish to compile
163 present in this list should be pruned (we don't need to return the
164 meta targets because they aren't mapped back to tests, and we don't want
165 to build them because we might build too much).
189 graph at all). We can't tell these two apart, so we should ignore missing
194 and so we should return which targets are missing so the caller can
200 were modified, but in rare cases we can hit a race where we try to
219 `all` to Ninja (at least given how GN and GYP work); however, we
220 don't want to take advantage of this in most cases because we don't
223 to analyze that we wanted to use no arguments instead of an empty
233 not be able to determine a correct answer (point 7 above, where we return
234 "Found dependency (all)"), we should also return the `test_targets` unmodified
240 Continuing the example given above, suppose we have the following build
279 Using the same patch as Example 1, assume we wish to run only `wtf_unittests`,
359 * we should push as much logic as we can into the source repositories
366 * we found that during the SVN->GIT migration the ability to flip bot
384 On the bots, we will disable `gyp_chromium` as part of runhooks (using
387 At the moment, we expect most developers to either continue to use
389 use for GYP at all. We may revisit how this works once we encourage more
390 people to use GN full-time (i.e., we might take `gyp_chromium` out of
399 Instead, we have one config per unique combination of flags only.
402 `mac_rel_bot`, we just have `rel_bot`.
405 of flags that we need to support, but *not* which flags are used on which
408 It may be that we should really track the latter. Doing so is just a
420 the GYP->GN migration is done, and so we should not add things for