branch protection checks in PR #10 are not recognized

Question

branch protection checks in PR #10 are not recognized

patrickersing opened this issue a year ago · 12 comments

In PR #10, there are some weird problems with status checks from the branch protection. After modifying the ci.yml the status checks got stuck. As can be seen in the picture below, initially while the workflow is running, checks are recognized:

However, when the workflow finishes the status gets stuck and switches to the following output:

To fix this we merged the new CI workflow to main (see #12), so now the workflow is identical to main, but the checks are still stuck.

Does anyone have an idea how to fix this, or what else we could try?

Answer 1 · 2024-01-12T12:27:55.000Z

I just closed and re-opened the PR to trigger CI again. Let's see what happens now.

Answer 2 · 2024-01-12T12:58:26.000Z

The CI has finished now, but the status checks still remain unchanged.

Answer 3 · 2024-01-12T13:02:42.000Z

Can you try opening a new PR with a random code change (e.g., just add a new blank line to src/TrixiShallowWater.jl) to verify that this is not a problem of this PR but a general one?

Answer 4 · 2024-01-12T13:40:39.000Z

@sloede: @ranocha just opened a new PR #14 one hour ago, where the status checks seem to work fine. So it seems like a problem specific to #10.

Answer 5 · 2024-01-12T13:47:42.000Z

Maybe just try to create a new branch and copy over the changes from the other one, opening a new PR. If the new PR works as expected, you can just close the old one, reference it from the new one (for comments, commit history etc.) and then proceed merging the new one

Answer 6 · 2024-01-12T13:53:44.000Z

I think that's a good idea, if this works it will be an easy solution. I will give it a try.

Answer 7 · 2024-01-12T16:23:52.000Z

After I commited the changes from #10 into the new PR #15 we get the same problem. So it must somehow be related to these changes.
Is it possible that this is related to the failing coverage? Is there maybe a setting that skips the report of the other status checks if the coverage fails?

Answer 8 · 2024-01-12T16:26:24.000Z

Honestly, I don't see how. It would be OK for me to just check the checks manually though, merge this PR eventually (after convos have been resolved), and tehn hope that the next PR will; not suffer the same issues 😬

Answer 9 · 2024-01-12T17:16:49.000Z

I was now able to fix the problems in the original PR #10 by commenting the unused lines. It really seems like somehow the coverage check is causing these problems.

Answer 10 · 2024-01-15T09:50:44.000Z

Does anyone have an idea how this could be related?
Even though it seems to be working now that the coverage is addressed, I think the problem still persists and I expect it to pop up again next time the coverage drops.

Answer 11 · 2024-01-15T11:28:17.000Z

No idea. I recommend to move forward and deal with it if it indeed pops up again

Answer 12 · 2024-01-16T16:48:32.000Z

As discussed in #16, removing the required check for coveralls seems to fix this problem, so I'll close this issue.
Thanks for the help!