Buildbot vs GitLab CI: What are the differences?
Developers describe Buildbot as "Python-based continuous integration testing framework". BuildBot is a system to automate the compile/test cycle required by most software projects to validate code changes. By automatically rebuilding and testing the tree each time something has changed, build problems are pinpointed quickly, before other developers are inconvenienced by the failure. On the other hand, GitLab CI is detailed as "GitLab integrated CI to test, build and deploy your code". GitLab offers a continuous integration service. If you add a .gitlab-ci.yml file to the root directory of your repository, and configure your GitLab project to use a Runner, then each merge request or push triggers your CI pipeline.
Buildbot and GitLab CI can be primarily classified as "Continuous Integration" tools.
"Highly configurable builds" is the primary reason why developers consider Buildbot over the competitors, whereas "Robust CI with awesome Docker support" was stated as the key factor in picking GitLab CI.
Buildbot is an open source tool with 4K GitHub stars and 1.37K GitHub forks. Here's a link to Buildbot's open source repository on GitHub.
WebbyLab, Infoxchange, and Dial Once are some of the popular companies that use GitLab CI, whereas Buildbot is used by Mozilla, Animoto, and Fetch Robotics. GitLab CI has a broader approval, being mentioned in 210 company stacks & 93 developers stacks; compared to Buildbot, which is listed in 7 company stacks and 6 developer stacks.
What is Buildbot?
What is GitLab CI?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
What are the cons of using Buildbot?
What are the cons of using GitLab CI?
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
We use GitLab CI because of the great native integration as a part of the GitLab framework and the linting-capabilities it offers. The visualization of complex pipelines and the embedding within the project overview made Gitlab CI even more convenient. We use it for all projects, all deployments and as a part of GitLab Pages.
While we initially used the Shell-executor, we quickly switched to the Docker-executor and use it exclusively now.
We formerly used Jenkins but preferred to handle everything within GitLab . Aside from the unification of our infrastructure another motivation was the "configuration-in-file"-approach, that Gitlab CI offered, while Jenkins support of this concept was very limited and users had to resort to using the webinterface. Since the file is included within the repository, it is also version controlled, which was a huge plus for us.
We are using GitLab CI and were very happy with it. The integration of all tools like CI/CD, tickets, etc makes it very easy to stay on top of things. But be aware, Gitlab currently does not have iOS build support. So if you want to exchange that for CircleCI / Codeship to have to invest some effort. We are using a managed Mac OS device and installed the Gitlab runner there, to have iOS builds.
We use Gitlab CI to unit and component test all of our application/components/modules. Therefore we use Docker runners.
GitLab CI is extremely flexible and easy to use. We also enjoy the elastic build infrastructure which is Docker based.