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
I change file A in my PR, which triggers workflow run check_A. The check fails.
I now add a new commit, changing file B. This triggers check_B which succeeds.
I would expect that
Github still shows me that check_A failed earlier or
Github would retry check_A to make sure it works now.
None of this happens, it only shows check_B which is green and I can happily merge, even though check_A is still not fixed.
How do other teams solve this?
The obvoius solution seems to be to always run check_A, even when file B changes. But that seems unnecessarily expensive, if file B has no relation to check_A. It would make more sense to me to still show the check as failed in the PR until I change something that triggers check_A again.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
The following scenario:
I change file
A
in my PR, which triggers workflow runcheck_A
. The check fails.I now add a new commit, changing file
B
. This triggerscheck_B
which succeeds.I would expect that
check_A
failed earlier orcheck_A
to make sure it works now.None of this happens, it only shows
check_B
which is green and I can happily merge, even thoughcheck_A
is still not fixed.How do other teams solve this?
The obvoius solution seems to be to always run
check_A
, even when fileB
changes. But that seems unnecessarily expensive, if fileB
has no relation tocheck_A
. It would make more sense to me to still show the check as failed in the PR until I change something that triggerscheck_A
again.Beta Was this translation helpful? Give feedback.
All reactions