Yes, ideally. Then again, I've caught plenty of bugs checking it out and running it locally.

The CI pipeline may not wholly be in your team's control. I've worked at places where a 'devops' team had too much control, liked to tinker all the time and often broke stuff. Nothing we could do - devops were gods and didn't take input from anyone.

Should I not do check it out locally and instead spend months and political capital arguing for more in the CI (which the PM would argue slows down velocity - and will win)?

Pragmatism and workarounds are often employed in non-bigtech enterprise companies...

edit: I also meant 'poke around' as in do a bit of informal QA. Again, your test and QA team might not be perfect...

There are times where it is reasonable, especially for bug fixes where there is a test to explicitly check that the bug is fixed. In that case, I might check out the code, revert the fix, and ensure that the test fails. There have been a few times I did that and the test still succeeded, so I can confirm that the test is not testing the right thing (in a very mature project, complexity or test settings can obscure what your test is actually doing, especially if it is an E2E test).

I have done a similar thing. I teach juniors to follow a strict test-driven development style when handling bug fixes. Write the missing, and failing, test first, then make the tests pass. (I also recommend using this approach for everything). But you can't tell if they've actually done this. It makes me think that this should be automated. Seems fairly straightforward to do in test frameworks that keep the tests in separate files. Bit harder if they're in the same files, like Rust.

It can be! And maybe even should be. But I've never seen it.

A great idea, though; when we finally get automated testing in CI, I'll certainly suggest it :)

That wouldn't necessarily compile though, eg if the fix involved changing a function signature or adding new functions.

Yup, same here

There can still be value in configuring your local IDE to emit more warnings than the centralized linter does, and looking at those warnings in your IDE.

This can help you identify additional pieces of feedback that you might have missed by just reading the code in a web interface.