GitHub Actions vs BitBucket Pipelines vs GitLab CI/CD

Choosing a Continuous Integration / Deployment tool to build, test, and deploy your code can be hard due to the wide number of options available. In this article, I describe the main characteristics of three of the most known services.

I'm going to talk only about the cloud version of each service, not about the self-hosted version in your own infrastructure.

Syntax

GitHub Actions looks for workflow YAML files (.yml or .yaml) stored in the .github/workflows directory of your repository. These files describe which events will trigger the workflow, the base operating system, and what jobs and steps will be run.

Events can be something like pushing to a branch, creating a pull request, or running a workflow periodically (e.g: every day at 08:00 am) based on a cron expression. Every job has a name and a list of steps. If you want to know more about GitHub Actions you can read the How to start using GitHub Actions post.

This is an example of a GitHub Actions workflow file:

name: Rushflow CI

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      - name: Run a one-line script
        run: echo Hello from Rushflow

Bitbucket Pipelines makes use of a YAML file bitbucket-pipelines.yml located at the root directory of the repository. This file stores the pipeline description with the base image and the list of steps to run. There is a default section with the default pipeline and a branches section to specify different steps for custom branches.

This is an example of a Bitbucket Pipelines file:

image: node:10.15.0

pipelines:
  default:
    - step:
        name: Build and test
        script:
          - npm install
          - npm test
  branches:
    staging:
      - step:
          name: Hello
          script:
            - echo "Hello from Rushflow"

If you want to know more about the pipelines syntax you can read the Get started with Bitbucket Pipelines documentation page.

GitLab CI/CD expects a YAML file named .gitlab-ci.yml located at the root directory of the repository (this path can be customized if needed). This file defines the order of stages of the pipeline and the commands to run for each stage.

This is an example of a GitLab CI/CD file:

stages:
  - build
  - test

build-app:
  stage: build
  script:
    - echo "Hello from Rushflow"
    - npm install

test-app:
  stage: test
  script:
    - echo "Testing app"
    - npm test

Operating Systems Supported

Not all the services support the same build environments. Usually, you'll have enough with a Linux environment but sometimes you'll need other environments like Windows or macOS to be able to build iOS apps.

GitHub Actions supports Linux, macOS, and Windows Server.

Bitbucket Pipelines only supports Linux environments at the moment.

GitLab CI/CD supports Linux, macOS (beta), and Windows Server (beta) at the moment of writing this article.

Docker support

There are some cases where you want to run your build inside a Docker container. All three of them support this feature.

To get more information about how to achieve this read Running jobs in a container for GitHub Actions, Use Docker images as build environments for Bitbucket Pipelines or The Docker executor for GitLab CI/CD.

Extensibility

GitHub has an Actions Marketplace with thousands of actions ready to use. These actions allow us to improve our workflow with things like installing language environments, caching data between jobs, or deploying a project with just a couple of lines of code. This marketplace is a great advantage of GitHub over other services. And if you don't find the action you need you can create your own action and publish it in the marketplace.

Bitbucket doesn't have an "action" concept like GitHub, the only option is to make use of existing Docker images and run custom scripts manually.

GitLab also doesn't have the concept of "action" but it provides the concept of "Auto DevOps" which helps with tasks like detecting the code language, building and testing the application, scanning for vulnerabilities, or deploying the application.

Free tier

These services have a free tier so you can start using any of them for free.

GitHub Actions free tier gives you 2000 minutes/month and 500 MB of storage.

Bitbucket Pipelines free tier has 50 build minutes/month and 1 GB of storage.

GitLab CI/CD free tier offers 400 minutes/month and 5 GB of storage.

Price / extra minutes

If the free tier is not enough you will need to pay for extra more minutes. In GitHub, extra minutes are priced based on the operating system of the build: $0.008/minute for Linux builds, $0.08/minute for macOS builds and $0.016/minute for Windows builds. In Bitbucket the price is $10/month for 1000 extra minutes. In GitLab, the price is also $10/month for 1000 extra minutes.

If you are happy with your current plan you can just buy more minutes, but if you are interested in the features of higher plans they'll come with more minutes too.

Self Hosted Runners support

This article is limited to cloud runners managed by the provider platform. However, if you have special needs (like being able to fully customize your environment) you can host your own runners in your own infrastructure. Check the following resources if you are interested:

Hosting your own runners for GitHub Actions, Runners for Bitbucket Pipelines, or GitLab Runner for GitLab CI/CD.

My recommendation is to start always with the cloud/managed version of the runners and use self-hosted runners only if you really need them. The complexity of managing your own runners usually is not worth it.

Summary table

The following table summarizes the main features of every service:

Conclusion

Based on the syntax, interface, features, extensibility, and price GitHub Actions is the clear winner. It is not a coincidence that GitHub has the highest number of users and open source projects compared to other platforms.