Dagger in a GitLab CI pipeline: assessment
I evaluated Dagger against a monorepo running 2,000 CI jobs a month, separating pipeline changes from the runner, cache, and hardware constraints that remain.
I evaluated Dagger against a monorepo running 2,000 CI jobs a month, separating pipeline changes from the runner, cache, and hardware constraints that remain.
Using glab and the GitLab API to turn a self-hosted runner's job durations into GitLab.com SaaS compute-minute estimates.
A comparison of home hardware, GitLab.com, AWS, ARM64 cloud, local AMD hardware, and Hetzner for a monorepo running 2,000 CI jobs a month.
When auto_cancel: on_new_commit is configured, rebasing a merge request from the GitLab web UI can prevent the new pipeline from spawning entirely.
Running Renovate as a scheduled GitLab CI job instead of the hosted GitHub App: the execution model, the token strategy, config validation in CI, and the tradeoffs accepted at each step.
Five cache mechanisms layered on a single self-hosted GitLab runner to keep a Java + Node + Python + React Native monorepo fast without standing up an external cache service.
GitLab's recommended control-plane include looked like the clean fix for ~40 repeated rules blocks. I evaluated it, found it would break my manual fallbacks and my lint tool, and collapsed the duplicated if-blocks in place instead.
A lockfile change rebuilt five unrelated jobs. The fix was to stop using the lockfile as a build trigger and let the cache key encode toolchain changes instead.