> the single worst change is that you can't see the latest commit status from the repo screen. Instead, you get the commit hash, and have to click a tiny ellipsis button to get the commit message and the status indicator.
Omitting the commit message is a net improvement to me; I've found that the commit message of the random commit that happens to be at top of tree is completely unhelpful for someone browsing the repository, and especially someone new to the project.
However, showing the status indicator inline does indeed seem like a good idea.
That said...
> You cannot see if your default branch has passed CI/status checks now.
If it hasn't passed CI and status checks, it shouldn't be in your default branch.
(There are cases where periodic status checks may get re-run after merging, such as checking if your default branch builds with more recent versions of software than it was originally tested with. But the normal CI and status checks should run before merging.)
It's not so clear cut. Most places I've worked, we don't build artifacts (docker images, whatever) until there's a merge to master or a tag has been pushed. This automatically means that even though your tests remain green, you still want the status check for the stuff that isn't relevant inside a PR.
For us, if the status is red in master, it doesn't mean the code is wrong, it means something went wrong in the deploy pipeline.
> Most places I've worked, we don't build artifacts (docker images, whatever) until there's a merge
The projects I've worked on have used a bot for merges, and that bot handles building artifacts. In some cases, there's a lighter CI for "this looks reasonable", and then the full CI (including building artifacts and running more extensive test suites on every supported platform) runs before merging.
> If it hasn't passed CI and status checks, it shouldn't be in your default branch.
Broken master is inevitable in a large enough project. Really what you want is to be able quickly fix a broken master.
By all means keep a perfect master if you have a toy project but once things have several developers hacking on a project with multiple artifacts and hundreds of thousands or millions of lines of code then you need to accept a broken master.
> once things have several developers hacking on a project with multiple artifacts and hundreds of thousands or millions of lines of code
That's exactly the case where you need more strictness about passing tests and CI before getting merged.
It amazes me when I come across a major project where the latest committed version often doesn't even build, let alone pass tests.
Yes, there are absolutely cases where you can't test everything; for instance, if you have complex combinatorial configurations and one obscure configuration fails. But that's a far cry from "inevitable in a large enough project". On the contrary, it's more important to avoid in a larger project.
Omitting the commit message is a net improvement to me; I've found that the commit message of the random commit that happens to be at top of tree is completely unhelpful for someone browsing the repository, and especially someone new to the project.
However, showing the status indicator inline does indeed seem like a good idea.
That said...
> You cannot see if your default branch has passed CI/status checks now.
If it hasn't passed CI and status checks, it shouldn't be in your default branch.
(There are cases where periodic status checks may get re-run after merging, such as checking if your default branch builds with more recent versions of software than it was originally tested with. But the normal CI and status checks should run before merging.)