Replies: 4 comments 1 reply
-
And may also break bisecting if that requires the usage of the same (or Notes on verification: If the checks do not appear on the main PR page (e.g.: [1] #4229 |
Beta Was this translation helpful? Give feedback.
-
I completely agree. MRs should only be merged when CI passes. Should we maybe move this thread into a discussion? I'm not sure how this issue is actionable, or what the conditions are for closing it. |
Beta Was this translation helpful? Give feedback.
-
That makes sense; I'll move it. I'm not very familiar with the discussions feature, so I didn't think to open |
Beta Was this translation helpful? Give feedback.
-
As mentioned on #4297, CI is broken on master again, likely due to the merge
of #4229, which was already failing a check before being merged.
When a PR that breaks CI is merged, every subsequent commit appears to do so as
well, which makes good commits/PRs look like they break something and may let
broken commits get merged without being noticed (which defeats the purpose of
having a CI IMO).
Personally, both issues make me want to avoid opening PRs until that is fixed.
With that said, can we agree on not merging PRs that break CI, especially in
the case of basic checks like
build_and_test
?The alternatives being to either fix the PR before merging or to change the CI
checks before merging if they're too onerous and/or pedantic. Note that in the
latter's case, ideally the PR branch would be rebased to master before merging,
so that the workflow runs again and checks that nothing else is broken.
Cc: @glitsj16 @netblue30 @reinerh @rusty-snake @smitsohu (as participants
of #4229 and #4256)
Beta Was this translation helpful? Give feedback.
All reactions