5 ms·
As an example, if you forget a file before pushing; all local tests will pass and abject failure remotely. You can do local checks for that sort of thing, but
by w0m 8y ago
As an example, if you forget a file before pushing; all local tests will pass and abject failure remotely. You can do local checks for that sort of thing, but it's ~impossible or at least impractical to catch every case through automation even when developer does due diligence.
- hinkley 8y agoImpractical is the key. So many people focus on how often the build is broken. That’s not the important part in CI. The important part is how often (% of day) the codebase is broken. It’s not how often you break the build that kills the team. It’s how long it stays that way. Breaking it twice a week for five minutes each is better than breaking it once a month for an hour or two.
- closeparen 8y agoWhy would a broken build affect the team? Are you pushing changes to master that don’t pass CI?
- hinkley 8y agoWhat don't you like about the other 5 answers you got to this question? The point of CI is to identify integration issues, not a blame assignment system (the loaded way you ask the question is really not helpful). So we can work faster. Not so we can spend all day second guessing our push being afraid we will make the build red. Any commit can have integration issues. With enough people committing, there is a build going on all day long. It won't always be ships passing in the night.
- closeparen 8y agoThe answers given above are 1) forgetting to “git add” and 2) test suite takes too long. These are fine reasons to offload testing of your PR to a CI system, but why would you be merging changes that potentially break the build? Our highest-commit-volume repos have a queue system doing test-then-land. There’s still no way a change set that breaks the build gets in the way of one that doesn’t.
- aeorgnoieang 8y agoWouldn't someone need to fix a broken build? Won't that take time, e.g. five minutes or two hours (or whatever)? And wouldn't it better to break it in a way that it can be fixed quickly? I guess that it's possible that your code merging workflow allows everyone to work completely independently but some teams don't (and others probably can't). So a broken build is an impediment to other working being done.
- closeparen 8y agoBecause it’s only your PR/diff/changeset that’s broken, and you don’t merge broken code? Are you talking about a scenario where people are just freely pushing to master without a review/CI step? If you recognize the problem with this, why is “deter people from breaking a post-merge CI process” better than “make your CI process pre-merge”?