Migrated 200 engineers from Jenkins to GitHub Actions. Scale exposed problems Jenkins never had.
Main breakages:
**Concurrency and Queueing**
* Default runners: 20 concurrent jobs **per repo**. Hit this immediately with monorepo.
* Enterprise runners: 500 job queue limit **per organization**. Caused pipeline gridlock during peak dev hours.
* Workaround required manual queue management and splitting workloads.
**Configuration Fragility**
YAML anchors and aliases (`&` / `<<: *`) are not natively supported. Complex shared workflows broke.
Had to refactor to reusable workflows or composite actions. Example of the break:
```yaml
# This DOES NOT WORK in Actions
.base: &base
runs-on: ubuntu-latest
steps:
- run: echo "base step"
job1:
<<: *base # ERROR
steps:
- run: echo "job1"
```
**Cost Surprise**
* Private runners underutilized initially, public runner minutes burned faster than forecast.
* Storage costs for artifacts/logs built up unseen. No built-in retention policy by default.
* Lesson: Set artifact retention and runner autoscaling rules **before** cutover.
**Permission Blowback**
Moving from Jenkins' granular per-job permissions to GitHub's repo/org-level secrets and permissions was a shock. Teams used to isolated credentials now had broader exposure. Required a re-architect of secret management.
null
The concurrency limits you hit are brutal at scale. I've seen teams get burned by that 500 job queue ceiling on Enterprise too - it forces a weirdly manual "queue management" mindset that defeats the purpose of automation.
On the YAML anchors point, that's a silent killer. So many CI configs are built on those DRY patterns. The pivot to reusable workflows feels heavier, but the versioning and explicit inputs can actually help at your scale, even if the migration pain is real.
Did the permission shift from Jenkins' job-level controls to GitHub's repo/org model cause any security review bottlenecks, or did your team find a workable pattern for it?
Still looking for the perfect one
The configuration fragility you mentioned is a real productivity sink. We also had to ditch YAML anchors, and while reusable workflows are more explicit, they introduced a new problem: version pinning.
Everyone defaulted to referencing the main branch of our shared workflow repo, which meant a broken merge could cascade and take down every pipeline simultaneously. We had to enforce a convention of tagging stable releases and pointing to tags, which added overhead but saved us from a few outages.
Did you run into similar issues with workflow version management after the refactor, or find a better pattern?
Interesting point about artifact retention - that's not something I'd considered. How do you even set up retention policies for those? Is it just a repo setting, or do you need something extra in the workflow yaml?
Also, your point about permissions makes me nervous for our own migration. Our Jenkins setup has some really specific job permissions. Does GitHub Actions really only have repo/org level? That seems... broad.