You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A few times in CI Council we've discussed how we enforce that developers reference the tracking issues for failing tests.
One possible way to enforce this would be to hook into the runfo triage issues and produce a GitHub Check on PRs to track the failing tests. The check would be green there were no failures or if every job (for Timeline queries) or test (for Test, Helix Log, etc. queries) that failed matched an open triage issue. Otherwise, the check would be red. This would enable better tracking for ensuring that PRs correctly reference why there are failing tests before merging on red.
The text was updated successfully, but these errors were encountered:
jkoritzinsky
changed the title
GitHub check for failures all known
GitHub check for "failures all known"
Nov 5, 2020
I've had similar thoughts. I do think whatever system we decide on for tracking test failures is going to have a behavior similar to this. Probably the simplest approach to start with is a bot that just opens a comment box detailing the failures which are known / not known.
A few times in CI Council we've discussed how we enforce that developers reference the tracking issues for failing tests.
One possible way to enforce this would be to hook into the runfo triage issues and produce a GitHub Check on PRs to track the failing tests. The check would be green there were no failures or if every job (for Timeline queries) or test (for Test, Helix Log, etc. queries) that failed matched an open triage issue. Otherwise, the check would be red. This would enable better tracking for ensuring that PRs correctly reference why there are failing tests before merging on red.
The text was updated successfully, but these errors were encountered: