search

matthewkmayer / matthewkmayer.github.io

Web site, with words
MIT License
3 stars 1 forks source link

How Bors relates to continuous integration (CI) #102

Open matthewkmayer opened 4 years ago

matthewkmayer commented 4 years ago

bors is a tool that prevents semantic conflicts by running a build pipeline as if the requested change was merged.

Write an essay on if this fits continuous integration or not. See CI Theater for definitions, patterns and antipatterns.

Initial thoughts: bors by itself does not enable continuous integration because it doesn't force continuously integrating work back into the main branch. Like all build systems, it can be used as such, but it's easy to fall into the same style of trap where automated build/test is confused with continuous integration.

Also cover TravisCI's speculative mergability analysis:

TravisCI was the first CI service to automatically predict a GitHub pull-request’s mergeability AND build success/failure as if they had landed in master. Specifically:

  1. a speculative merge back to the master/trunk/mainline - only into working-copy as it is for analysis only
  2. all the classic compile/unit-test/integration-test/functional-test steps of the regular build, in situ The speculative merge is discarded every time after #1 (if it can’t merge) or #2 (regardless) - the actual merge result is never pushed off the build server to the remote (in Git terms). It is only the “is this buildable and mergeable or not” notification that was desired from the exercise.
matthewkmayer commented 4 years ago

https://martinfowler.com/bliki/ContinuousIntegrationCertification.html is another good source to cite, especially:

The problem of CI theater leads some people to use the name Trunk-Based Development, arguing that SemanticDiffusion has rendered the term “Continuous Integration” useless. While I understand their view, I believe that we shouldn’t give in to semantic diffusion, instead we need to keep working at re-explaining the proper meaning of Continuous Integration, just as we should with other terms under this kind of semantic assault (such as “agile” and “refactoring”). After all Kent was quite clear in his definition of the term, and using another diminishes the important role he had in popularizing the technique via the Extreme Programming community.