Confirmed users
3,376
edits
m (→choosing a starting point: initial data) |
m (→how to find which job to retrigger: initial data) |
||
| Line 22: | Line 22: | ||
= how to find which job to retrigger = | = how to find which job to retrigger = | ||
Once you have the revision and config, now we need to figure out the job. Typically a test will fail in a specific job name which often is a chunk number. We have thousands of tests and run split across many jobs in chunks. These are dynamically balanced, which means that if a test is added or removed as part of a commit, the chunks will most likely rebalance and tests are often run in different chunks. | |||
Picking the first job is easy- that is usually very obvious when choosing the config that you are running against and pulling up the revision to start with. for example, it might be linux64/debug mochitest-browser-chrome-e10s-3. | |||
As a sanity check, I pull up the log file and search for the test name, it should show up as TEST-START, and then shortly after TEST-UNEXPECTED-FAIL. | |||
When retriggering on previous revisions, you need to repeat this process to ensure that if you select chunk 3 that the test exists, it is likely that the test could be in a different chunk number. | |||
= how many retriggers = | = how many retriggers = | ||
= what to do with the data = | = what to do with the data = | ||
= exceptions = | = exceptions = | ||