Hacker News Reader

Comment by trevinhofmann | Hacker News Reader

I've been enforcing every commit to both build and pass tests, but now I might only require each commit to build and each merge request to pass tests.

In that case, you can have a merge request with a commit to add a test and then another commit to fix it. As long as both commits build, bisect will still work.

I agree with having CI enforce both passing tests and working builds, but why would you want the build step to require passing tests?

View on HN

This is basically the approach that I take. I expect git log --first-parent (and git bisect --first-parent) on the main branch to pass full CI builds, but I'm increasingly more lax about individual commits the further you get out into the DAG. I think it way more useful to record the steps-in-progress than to toss them (especially when you are trying to debug the why or the how of a change months or years later from say a junior developer; it's a lot easier sometimes to see things like "oh, this was a test value meant to be replaced" when you see exactly which intermediate commit it was from deep in a PR).

(ETA: It's easy to forget that the I in CI stands for "integration" and was always focused on merges of changes more than specific changes.)

That's just terminology. When I said "does not build" I meant CI fails because a test fails. Of course the code would compile or what other steps you might have.

Change the CI to test that every commit builds and every merge request passes tests. If we don't enforce the tests to pass for every commit, that solves the problem. Right?

Reply on news.ycombinator.com