Hey everyone, still getting the hang of CI/CD setups here. 😅
I'm planning a pipeline for a small Node.js project and want to speed things up with parallel jobs. I've read the docs, but I'm confused about the *actual* parallel execution limits on the free/cheap tiers for GitHub Actions and GitLab CI.
For example, if I have a matrix of 10 test jobs, will they all run at once? I've seen mentions of "concurrent jobs" limits based on the OS and account type, but how does that work in real usage?
Has anyone done a side-by-side test? I'm especially curious about:
- The real-world throughput for a burst of jobs.
- If there's a queueing difference.
- Any gotchas with the configuration.
Just looking for some practical, beginner-friendly insight before I commit to one platform.
I'm a full-stack dev at a small SaaS, we handle about 50 deployments a month for a Node.js/Postgres app using CI for testing and Docker builds.
Here's a breakdown from running both, focusing on the free tiers:
1. **Free Tier Concurrent Job Limit:** GitHub Actions gives you 20 concurrent jobs across all repositories under the free plan. GitLab.com's free tier offers unlimited concurrent jobs, but with a shared runner concurrency limit per pipeline; in practice, a single pipeline with 10 jobs often runs all 10 at once on their shared infrastructure.
2. **Queueing & Startup Time:** GitHub Actions jobs queue at the account level if you hit the 20 limit. GitLab's free shared runners have a queue time that varies heavily by time of day; I've seen waits from 30 seconds to 8 minutes for a job to be picked up, but once a runner accepts a pipeline, its matrix jobs fan out quickly.
3. **Matrix Strategy Throughput:** For a 10-job test matrix on the free tier, GitHub Actions will run them all concurrently as long as you're under your 20 total account jobs. GitLab will also run them concurrently, but you might hit "No available shared runner" errors during peak times, causing a few jobs to lag behind.
4. **Configuration Gotcha:** In GitHub Actions, your workflow file's `matrix` generates individual jobs, and they all count toward your concurrent limit immediately. In GitLab CI, you must define parallel jobs explicitly in `.gitlab-ci.yml` using the `parallel:` keyword; without it, you're just running serial stages.
I'd pick GitHub Actions for this small Node.js project because the free tier's concurrency is predictable and the queue is generally shorter for public repos. If your project is private and you need more consistent free concurrency, GitLab can be better, but ask yourself: how time-sensitive are your builds, and are you okay with occasional runner delays?