4 ms·
You only need to run CI on Production, and you can squash commits. Generally a release is once per week, and at Oktas level you have a release engineer.
by cellis 4y ago
You only need to run CI on Production, and you can squash commits. Generally a release is once per week, and at Oktas level you have a release engineer.
- samwillis 4y agoYes, I suppose I could be taking the anecdote too literally. It's much more likely they are only running all test on push to main / against pull requests / on code review.
- TheCoelacanth 4y ago300 developers' work being crammed together into a weekly release without having their contributions pass CI first sounds absolutely hellish for whatever poor bastard has to track down who broke the build.
- nicoburns 4y agoThere's tooling like bors that will rollup commits together and run CI on them before merging to master. If it fails then the commits will be retried individually.
- TheCoelacanth 4y agoI suppose so, but that cuts down on the number of CI runs when merging to master because the vast majority of commits being merged to master don't fail the build. In a typical bors workflow, that holds, because you do a CI run before attempting to merge, so commits don't break the build except in the rare case that two commits that are individually okay combine in a way that breaks. If you get rid of the individual run before merging, your combined runs will hardly ever pass, so it won't cut down on the number of runs.