Getting started with Github Actions for Bitbucket Pipelines User
This is a quick rundown of similarities and differences between Github Actions and Bitbucket Pipelines. This guide would be helpful for anyone who is using bitbucket pipelines and is in process of moving their CI/CD to Github Actions.
Workflow Configuration Files
Workflow configuration files are written in YAML files and stored in repository. Bitbucket allows you to configure only single YAML file to store your workflow. This functionality slightly differs on Github Actions. You will need to define each workflow in separate yaml files. Workflows can include one or more jobs, jobs include one or more steps.
Triggers
Bitbucket pipelines are triggered on commit and these can be configured up to pull requests and branches. You can configure custom workflows that can be triggered manually. Github gives you flexibility to trigger a workflow on more code commits. For example, you can trigger workflow when a page is added, or someone watches the repository.
Manual Trigger
Bitbucket pipelines allowed you to have manual trigger on step and stages. This would allow you to promote a step manually and is particularly handy if you want to run deployment to a stage manually. Github Actions gives you this same functionality with approvers. For this environment must be setup and only after approval on steps, a job can run on a environment.
Migrating pipes to actions
Both bitbucket pipelines and GitHub actions provide a mechanism to reuse and share tasks in a workflow. Bitbucket pipelines uses a concept called pipes where Github has actions. There are community-built actions that are readily available for use for common tasks including uploading artifacts, configuring AWS credentials.
Steps Reusability
YAML anchors and aliases are supported in Bitbucket Pipelines. This is not supported in Github Actions however, reusability is supported via a concept of matrix via which you can run multiple jobs across different environments/platforms.
Variables and secrets
Bitbucket Pipelines allows setting both non-secrets and secrets, but GitHub only allows you to add secrets per repository/environment. Any non-secret environment variable needs to be defined in the workflow yaml file. One of the quirks of Bitbucket UI was when setting up variables, if you mistakenly added variables with whitespace while copy-pasting, this was not visible on UI. If you didn’t have mechanism to check for this, you would be initialising wrong parameters to your services.
Dependencies between Jobs
Both pipelines allow you to set dependencies for a job. Jobs in Github run parallel by default. While on bitbucket, you need to configure parallel steps. In Github actions, jobs can be tied together sequentially with “needs” key. This supports array, so you could wait for multiple parallel jobs to complete before running a job.
Scheduling Workflows
Both support running workflows at a specific interval. In Bitbucket Pipelines, schedules are configured with the UI, while in GitHub Actions you can trigger a workflow on a scheduled interval with the “on” key.
Conditionals
Bitbucket Pipelines allow steps to be run if the changed files match configured change-sets. This is more flexible in Github Actions. You can configure jobs to execute based on if conditionals which means you can execute jobs on more than just changed files.
Instance Size
Bitbucket by default runs all the pipelines on machines with 4GB RAM. You can configure this to use 2x size (8GB RAM). All Github actions are run under 2-core CPU, 7GB of RAM Memory. That means, you will have faster build by default.
Artefacts
If you rely on CI/CD platform’s artefact storage and do not use external storage like S3, you have more flexibility with Github Actions. Unlike Bitbucket, where artefacts are stored up to 14days, Github allows you to configure retention period for the artefacts up to 400 days for private, internal and enterprise repos.
Concurrency
Bitbucket by default stops any concurrent build that is using the same deployment environment. You need to manually configure concurrency in github actions to enable this behaviour.