Confirmed users
3,376
edits
(→exceptions: initial data) |
(→how many retriggers: backfilling) |
||
Line 36: | Line 36: | ||
* we do not run every job/chunk on every push, so it could be 30 failures in 75 data points | * we do not run every job/chunk on every push, so it could be 30 failures in 75 data points | ||
* there could be retriggers on the existing data and we could have 3 or 4 failures on a few pushes making it failing less than 20% | * there could be retriggers on the existing data and we could have 3 or 4 failures on a few pushes making it failing less than 20% | ||
= backfilling = | |||
In the case where we run each job every 5th push or as needed, we will have a larger range of commits from passing to failing. In this case we need to backfill. | |||
Here we have to backfill first, then once the job is scheduled we can retrigger it. Caution here is that if a test is in a chunked job, you might need to backfill all the jobs- a trick is to see if it is in chunk X before/after the backfill, the chance of it being in the same chunk in the backfill range is very high. | |||
Also when backfilling if a build fails, then you will not be able to pinpoint the specific commit. This is the same when people land multiple patches/bugs in the same commit- we just have less granularity. | |||
= what to do with the data = | = what to do with the data = |