GitLab CI
Last updated: Nov 4, 2026
Rationale
GitLab CI is the system that orchestrates all the CI/CD workflows of Fluid Attacks. These workflows are the base of all the development cycle of Fluid Attacks. With it, Fluid Attacks can do these tasks:
- Run automated processes on each commit
- Automate application testing
- Automate application deployment
- Automate all the QA tests that it can think of
Because its workflows are very automated, Fluid Attacks can deploy applications many times each day without a decrease in quality or security.
These are the primary reasons why Fluid Attacks selected GitLab CI and not other alternatives:
- It is Open source.
- Built-in support for GitLab: GitLab is the platform of the product repository of Fluid Attacks. Thus, it is an advantage for Fluid Attacks to easily integrate its CI solution with it. All the GUI capabilities, for example, pipelines, jobs, CI/CD variables, environments, schedules, and container registries, come from this integration.
- It supports pipelines as code: Fluid Attacks can write all its pipelines as code.
- It supports horizontal autoscaling: To run hundreds of jobs for many developers, all in real time, the system of Fluid Attacks must support horizontal autoscaling.
- It supports directed acyclic graphs (DAG): With this capability, Fluid Attacks makes its integrations as fast as possible, because jobs depend only on what they must depend on. It is necessary for a monorepo strategy like the strategy of Fluid Attacks.
- Very versatile configurations: Each piece of software usually has its own requirements to build, test, and deploy. Thus, GitLab CI gives a very large set of configurations, from parallelism, static pages, and services to includes, workflows, and artifacts.
- Very versatile infrastructure: The AWS autoscaler has configurations for S3 cache, machine type, maximum number of machines, spot instances, C5d instances, SSD disk usage, EBS disks, off-peak periods, tagging, maximum builds before destruction, and many more. A very versatile CI is important, because the development cycle of Fluid Attacks fully depends on it. Thus, Fluid Attacks expects it to respond like clockwork and to compute as fast as possible.
Alternatives
Fluid Attacks examined these alternatives, but it did not select them for these reasons:
- Jenkins: It did not support pipelines as code when Fluid Attacks reviewed it.
- TravisCI: It had to have licensing for private repositories when Fluid Attacks reviewed it.
- CircleCI: It did not support GitLab, it was very expensive, and it did not have as many parameters.
- Buildkite: Its review is pending.
Usage
Fluid Attacks uses GitLab CI for these tasks:
- To run all its CI/CD jobs
- To manage all its CI pipelines as code
- To configure its AWS autoscaler as code
- To implement a Continuous Delivery approach for its development cycle. Fluid Attacks automates all the process, including the deployments for development and production. But the GitLab bot must approve each merge request before Fluid Attacks can deploy changes to production. The review policy of the bot decides when a person must also approve.
Fluid Attacks does not use GitLab CI for very long schedules that continue for more than six hours. Examples are Analytics ETLs and Machine learning training. For these schedules, Fluid Attacks uses AWS Batch. This is because GitLab CI is not for jobs that continue for that many hours. Frequently, these jobs stop before they can end. The primary cause is the disconnection between the worker that runs the job and its GitLab CI Bastion.