Building a Multi-Pipeline CI Setup for Running Automated Tests in GitLab
Article Summary
Gojek's engineering team cracked a common CI/CD headache: how do you run automated tests from a separate repo without creating pipeline chaos?
When your QA tests live outside your application repository, running them on every code change gets messy fast. Akshay Maldhure from Gojek shares how they built a multi-pipeline setup in GitLab that combines development and testing workflows into one seamless process.
Key Takeaways
- Tests trigger automatically on app changes, not on wasteful scheduled runs
- Failures are tracked per code change, making debugging dramatically easier
- Reusable CI templates let multiple teams adopt the pattern quickly
- GitLab's needs keyword ensures tests wait for integration deployment
- Resource groups prevent pipeline collisions during concurrent deployments
By linking upstream app pipelines with downstream test pipelines, teams get better resource utilization and can block MRs on test failures.
About This Article
Gojek's QA teams were running tests on a schedule rather than with each code change. This wasted CI resources and meant developers had to wait longer to find out if their changes broke anything.
Akshay Maldhure's team set up GitLab's multi-pipeline architecture using CI templates. They used the `needs` keyword to connect app pipelines with test pipelines, and added `resource_group` to stop pipelines from running at the same time and conflicting.
Now tests run whenever code changes, making it easier to track and debug issues per application. The team stopped wasting resources on scheduled test runs that nobody needed. Merge requests can be automatically blocked if functional tests fail.