Need advice about which tool to choose?Ask the StackShare community!
GitLab CI vs Github Actions: What are the differences?
Introduction: GitLab CI and GitHub Actions are both continuous integration and continuous delivery (CI/CD) platforms that help automate software development workflows. While they serve a similar purpose, they have several key differences that make each platform unique.
Workflow Configuration: GitLab CI uses a YAML file called
.gitlab-ci.yml
to define the stages, jobs, and steps of a CI/CD pipeline. It follows a declarative approach, allowing users to specify the desired state of the pipeline. On the other hand, GitHub Actions uses YAML files called workflow files that are stored in the.github/workflows
directory. It follows an imperative approach, allowing users to define the exact steps to be executed.Built-in Integration: GitLab CI is tightly integrated with the GitLab platform, providing seamless integration with other GitLab features like issue tracking, code reviews, and container registry. GitHub Actions, on the other hand, is closely integrated with GitHub, offering native integration with pull requests, issues, and the GitHub ecosystem.
Parallel Execution: GitLab CI allows parallel execution of jobs by default, enabling faster CI/CD pipelines. It automatically distributes jobs across available runners, optimizing resource utilization. In contrast, GitHub Actions had a limited parallelism feature initially, but now also allows parallel execution, albeit with some limitations on the number of concurrent jobs depending on the user plan.
Pricing Model: GitLab CI is part of the GitLab platform, which comes with a different pricing structure based on GitLab's plans. It offers various tiers ranging from free to enterprise editions, with different features and capabilities. GitHub Actions, on the other hand, is included in all GitHub plans, including the free tier, allowing users to benefit from its CI/CD capabilities at no additional cost.
Third-Party Actions: GitHub Actions has a rich ecosystem of third-party actions available in the GitHub Marketplace. These pre-built actions provide additional functionality and integrations that can be easily added to workflows. GitLab CI also has a collection of community-contributed CI/CD templates, but the availability of pre-built actions is not as extensive as in GitHub Actions.
Deployment Environments: GitLab CI allows the definition of multiple deployment environments, each representing a stage in the software delivery pipeline. It facilitates the separation of tasks and enables easy promotion of code through different environments. GitHub Actions, on the other hand, does not have a built-in feature similar to GitLab's deployment environments, making it less suitable for complex multi-stage deployment scenarios.
In summary, GitLab CI and GitHub Actions differ in their workflow configuration, integration with the respective platforms, parallel execution capabilities, pricing models, availability of third-party actions, and support for deployment environments. The choice between the two depends on the specific requirements of the project and the development team's preferences.
We are a mid-size startup running Scala apps. Moving from Jenkins/EC2 to Spinnaker/EKS and looking for a tool to cover our CI/CD needs. Our code lives on GitHub, artifacts in nexus, images in ECR.
Drone is out, GitHub actions are being considered along with Circle CI and GitLab CI.
We primarily need:
- Fast SBT builds (caching)
- Low maintenance overhead (ideally serverless)
- Everything as code
- Ease of use
I think I've tried most of the CI tools out there at some point. It took me a while to get around to Buildkite because at first I didn't see much point given it seemed like you had to run the agent yourself. Eventually it dawned on me why this approach was more ingenious than I realised:
Running my app in a production (or production-like) environment was already a solved problem, because everything was already in some form of "everything as code". Having a test environment where the only difference was adding the Buildkite agent was a trivial addition.
It means that dev/test/prod parity is simple to achieve and maintain. It's also proven to be much easier to support than trying to deal with the problems that come with trying to force an app to fit into the nuances and constraints that are imposed by the containers/runtime of a CI service. When you completely control all of the environment the tests are running in you define those constraints too. It's been a great balance between a managed service and the flexibility of running it yourself.
And while none of my needs have hit the scale of Shopify (I saw one of their engineers speak about it at a conference once, I can't find the video now though ๐) it's good to know I can scale out my worker nodes to hundreds of thousands of workers to reduce the time it takes for my tests to run.
I would recommend you to consider the JFrog Platform that includes JFrog Pipelines - it will allow you to manage the full artifact life cycle for your sbt, docker and other technologies, and automate all of your CI and CD using cloud native declarative yaml pipelines. Will integrate smoothly with all your other toolset.
more configurable to setup ci/cd: * It can provide caching when build sbt, just add this section to yml file * Easy to use, many documentation
Weakness: * Need use gitlab as repository to bring more powerful configuration
Buddy is one of the most easy-to-use tools for CI I ever met. When I needed to set up the pipeline I was really impressed with how easy it is to create it with Buddy with only a few moments. It's literally like: 1. Add repo 2. Click - Click - Click 3. You're done and your app is on prod :D The top feature that I've found is a simple integration with different notification channels - not only Slack (which is the one by default), but Telegram and Discord. The support is also neat - guys respond pretty quickly on even a small issue.
Pros of GitHub Actions
- Integration with GitHub8
- Free5
- Easy to duplicate a workflow3
- Ready actions in Marketplace3
- Configs stored in .github2
- Docker Support2
- Read actions in Marketplace2
- Active Development Roadmap1
- Fast1
Pros of GitLab CI
- Robust CI with awesome Docker support22
- Simple configuration13
- All in one solution9
- Source Control and CI in one place7
- Integrated with VCS on commit5
- Free and open source5
- Easy to configure own build server i.e. GitLab-Runner5
- Hosted internally2
- Built-in Docker Registry1
- Built-in support of Review Apps1
- Pipeline could be started manually1
- Enable or disable pipeline by using env variables1
- Gitlab templates could be shared across logical group1
- Easy to setup the dedicated runner to particular job1
- Built-in support of Kubernetes1
Sign up to add or upvote prosMake informed product decisions
Cons of GitHub Actions
- Lacking [skip ci]5
- Lacking allow failure4
- Lacking job specific badges3
- No ssh login to servers2
- No Deployment Projects1
- No manual launch1
Cons of GitLab CI
- Works best with GitLab repositories2