> It'd be odd to run CI locally

Oh, I would if I could. Conceptually, not very different from running make and fixing any compiler warnings or failed tests before making a commit.

I think that's how a lot of CI gets started: locally runnable tests are automated to make sure they're always run before the commit lands.

Unfortunately automating CI often pulls a lot of server side infrastructure and platform specific mechanisms that break the ability to run it locally. I find it very frustrating to commit, push, wait for server to nag me, fix, commit again, push again, hope it works this time. It just creates a lot of noise and IMO doesn't flow very well. I'd prefer to be able to test everything locally as far as is possible.

One of the nice things about the project I work on is that things like eslint, stylelint, and the unit tests all work locally inside of Docker, so I can be sure I'm pushing code to the repo that won't be rejected by CI for code hygiene reasons. CI runs all that stuff as a check, but it's really there for the integration and end-to-end tests, and the build and deployment processes. If you can get your project to work that way it's really nice to have.

Sure, but the overwhelming majority of dev teams will run CI on remote branches. That's well after "commit". I think a pre-commit requirement for tests pass would be a turn off for me (I routinely rely on CI to tell me what's wrong with my code so long as it's on a private branch, so I can move onto something else while tests run).

I'm not sure what this is responding to in my comment. I certainly never meant to say anything contrary to what you're saying.