Loading today’s stories
Build1 distinct publisher3 min readUpdated
The queue was a budget cap wearing an engineering costume. Moving 22 of 34 repositories to GitHub Actions bought sub-minute starts and a bill that had to be tuned back down.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
A node group capped at 12 m6i.large instances because it already cost enough during normal hours [9] is a rate limiter with a spending policy bolted to it. It was doing unpaid hygiene work. Every redundant check in every pipeline was absorbed as queue time instead of arriving as an invoice line, which is why the team's own account describes a controller in good health sitting behind a useless queue [8]. Hosted runners removed the limiter, and the pipelines' real appetite showed up priced: $1,460 in the first month across 22 repositories [13], because every pull request was still running integration tests, image builds, dependency scans and a 19-minute Playwright suite [14].
The correction was subtraction, not a discount. Splitting checks by path, cancelling superseded runs and moving browser tests behind a merge-queue label brought the next month to $690 [15]: $770 removed, about 53 percent [19]. Per moved repository that is roughly $66 a month falling to about $31 [23], against an estate that averages about eight builds per repository on a busy weekday [24]. None of that was capacity work. It was a decision about how many times the same suite deserves to run.
What stays on Jenkins is now defined by capability rather than by preference: privileged network access, custom hardware, and scripted behaviour nobody wants to translate [4]. That leaves about 12 repositories unmoved [22] plus the deployment job that reaches a vendor appliance through a jump host [2]. The 480-line shared library of agent pod templates, the over-eager image pulls and the Docker-in-Docker sidecar that parks in ContainerCreating while a sibling job waits [7] all stay with them, as does the StatefulSet in EKS [6]. The ordinary Maven and Node work that used to justify keeping someone fluent in that library has left the building. The residual system is all exception and no volume.
The second gain is legibility. The team notes the Actions workflow puts more of its behaviour in front of a developer who never had controller administrator access, while Jenkins offers the most freedom and enough rope for each team to build a second deployment system inside a shared library [18]. That freedom is exactly what the retained jobs are made of.
GitLab CI was not rejected on features. It was rejected on ownership: a reasonable option where GitLab already holds source control, not something to introduce beside GitHub purely to displace Jenkins [5]. The operational reservation is narrower and worth keeping in view, that shared-runner queue time varies more with GitLab.com capacity than the team wants for release work [12].
One number the finance side did not connect: Jenkins node spend fell by roughly $510, and the team says its own reporting made that link about as obvious as a failed Helm rollback [16]. If the savings on one platform and the charges on another land in different reports, the migration will be judged on the bigger of the two.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
At 10:17 on a Tuesday, the team's release branch had 19 builds waiting behind a Jenkins controller that was technically healthy; the oldest job had been queued for 43 minutes.
The estate comprised 34 repositories, roughly 280 builds on a busy weekday, Java and Node services, Terraform plans, and one antique deployment job that talks to a vendor appliance through a jump host.
The team compared three paths: keep Jenkins on Kubernetes, move normal CI work to GitHub Actions, or run GitLab CI for teams already using GitLab's package and security features.
Their conclusion: GitHub Actions won for most application CI, while Jenkins stayed for jobs with network access, custom hardware, or years of scripted behaviour nobody wants to translate.
The team judged GitLab CI a decent choice if GitLab already owns source control, and said it would not introduce GitLab beside GitHub merely to replace Jenkins.
The Jenkins controller ran as a StatefulSet in EKS, with ephemeral Kubernetes agents created through the Jenkins Kubernetes plugin.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Detailed but wholly self-reported
The account is unusually specific — queue depth and age, node-group instance type and cap, per-build CPU/memory requests, autoscaler latency, three monthly bills, repository counts — which raises its evidentiary value above opinion. But every figure comes from one first-party post with no logs, dashboards, invoices or third-party corroboration, no methodology for how the bills were attributed, and no independent source in the cluster to check the comparison against. Several of the sharpest numbers in the story (net new spend, per-repository cost, repositories retained) are our arithmetic on the author's figures, not separately observed.
Real production migration, one estate
This is not a pilot narrative: 22 of 34 repositories were actually moved, Jenkins was deliberately retained for network- and hardware-bound jobs, credentials were re-plumbed onto OIDC, and two consecutive months of spend were observed after the cut-over. That is genuine production adoption with a measurable aftermath. It is also exactly one team's estate, with no evidence in the cluster of the pattern being adopted elsewhere, so the adoption signal is deep but very narrow.
Slightly understated
The framing is more cautious than the underlying material. The headline claim is a partition, not a platform victory; the article leads its own cost section with the admission that spend got worse before it got better, keeps Jenkins for the awkward job, declines to recommend adding GitLab beside GitHub, and calls out that finance reporting obscured the Jenkins saving. What it leaves unsaid cuts against it rather than for it — the net new spend figure and the peak combined position both had to be computed by us, and migration labour is never priced. Small negative rather than zero because the cost story is arguably worse than the tone implies while the operational win is stated plainly.
Self-published practitioner account, no disclosure
The structural incentives are visible and modest. This is a first-party engineering post on a developer publishing platform, where the author benefits reputationally from a tidy, quotable migration narrative and controls every number in it with no editorial or audit layer. There is no disclosed sponsorship or vendor relationship with GitHub, GitLab or AWS, and no disclosure statement either way; the recommendation is also partly self-limiting, since it endorses keeping the incumbent tool and rejects adding a second vendor. That combination points to mild, mostly reputational distortion pressure rather than commercial capture.
Internally consistent, externally unchecked
Confidence is limited chiefly by cluster structure: one publisher, one estate, zero corroboration. Within those limits the material is coherent — the capacity-cap diagnosis explains the queue, the per-PR workload explains the billing spike, and the tuning steps plausibly explain the drop, with all stated arithmetic reconciling. We are reasonably confident about what the team says it did and observed, and much less confident that the figures generalise, that the Jenkins saving is cleanly attributable, or that the numbers would survive an audit.
build
A 30-to-45-second timeout change, four approvals, no merge: the cost of a two-person gate1 distinct publisher
build
A NetworkPolicy in another repo broke invoicing while every dashboard reported success1 distinct publisher
build
The stability step is a branch, not a pipeline: inside one team's release-candidate discipline1 distinct publisher
build
A year without sprints: nine engineers, 36 services, and a WIP cap of eight graded B1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 21, 2026