[WIP] Test repair agent Part 2: update the pulse listener - #6421
[WIP] Test repair agent Part 2: update the pulse listener#6421evgenyrp wants to merge 12 commits into
Conversation
|
This is preliminary as I'm still reviewing and testing myself. Also, it might change when the agent Part 1 lands. |
Brings in the build-repair action-task and push-age gates alongside the Treeherder-based rewrite of the listener's failure filtering. Conflict resolution: - regression.py: kept the Treeherder-backed regression gate (per-push status from Treeherder, ancestor chain from mozci) and added master's is_stale_push, whose param is named `project` to match the module. - test_regression.py / test_consumer.py: master's build-path tests, which use the new get_task seam, plus the test-path suite. - README.md: one pipeline covering both paths, including master's action-task and push-age steps. Two changes outside the conflicts: - consumer.py auto-merged cleanly but was left broken: master changed taskcluster.get_hg_revision to take a task definition rather than a task id, while _process_test still passed the id, which would raise AttributeError on every test-failure message. It now fetches the task once and passes it on. - The same two gates master added to builds now also apply to test failures, since the signature change was made for them and the reasoning carries over: a backfill is not a new failure, and a failure surfacing days after its push is not worth repairing. Both run before the ancestor walk, which can block. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
|
Current state of things: Over ~86 minutes: ~116 failures rejected at the Treeherder gate, 4 runs triggered: |
Looking at treeherder for this: https://treeherder.mozilla.org/jobs?repo=autoland&revision=0faca76bc591445f1de70a0081901faea33c8242&searchStr=mochitest-browser-chrome&selectedTaskRun=c2YUKOVWS8KEqC3kvBqYVg.0. Can you also look at the other 3 triggered runs to see if they were successfully finding what needed to be found? |
| 1: "not classified", | ||
| 2: "fixed by commit", | ||
| 3: "expected fail", | ||
| 4: "intermittent", |
There was a problem hiding this comment.
The "intermittent" classification is manual, not sure how quick usually sheriffs are at applying it. CC @Archaeopteryx
| # Treeherder classifies a failing job shortly after we see the failure, so the | ||
| # gate waits for the job to be ingested before reading that verdict. | ||
| treeherder_ingest_poll_seconds: int = 30 | ||
| treeherder_ingest_max_wait_seconds: int = 240 | ||
| # How long to wait for a verdict once the job is ingested. Classification lands a | ||
| # few minutes after ingestion, and most test failures turn out to be intermittent | ||
| # or expected-fail, so waiting here rejects them before the ancestor walk. | ||
| treeherder_classification_wait_seconds: int = 300 |
There was a problem hiding this comment.
@Archaeopteryx if we wait this long and then the agent takes a few more minutes to analyze, do we risk sheriffs will already have run a backfill by the time the analysis is done?
This was a dry run. I added treeherder URLs to the logs for easier inspection. I'm going to deploy it with a daily limit and then we can look at what actual agent runs look like. |
Tested only locally with a dry run. I will redeploy it when the agent is landed
depends on #6375
fixes #6399