Janpot
commented
1 year ago With a slowing growing CI running times
Not that there could be no value in improving CI timings, but the data suggests differently. There has been a peak, but CI times are at a similar level to July. I'm not 100% sure what happened around beginning of september, I don't remember builds taking one hour. I do remember there to be a few circleci outages with delayed jobs, perhaps related?
IMO, once CI passes the two minute mark, I can't really use it in a synchronous way anymore. From that point on, if I want to increase efficiency, I'll have to find ways to asynchronously work around CI. e.g.
- Pick up a new task, similar to how I'd deal with waiting for reviews, doing more work in parallel. Treat CI as just another team member that reviews your code.
- If a piece of work has a part with high risk of breaking an integration test and a part with low risk, I do the high risk first, push it and work on the low risk part until CI has finished. Any red integration tests? Now I know what to single out locally and can continue working on the high risk part again.
That being said, it looks like the CI job taking most of the time is the docker one. And within that workflow, the docker build. I'm not sure there's any quick wins there, besides beefing up the machine. IMO, if we're going to start optimizing the docker build, I believe we should rather optimize for image size and not for build time as improving image size has direct user value.
Besides decreasing the monthly circleci bill. I personally don't feel like I would gain much from improving CI time with say 5 minutes (and neither would I lose much from it increasing 5 minutes).
As for render.com, after analyzing the build logs, I see it basically divided equally between dependency installation and next.js build (about 7, 8 minutes each). I find this rather on the long end for both of them and I wonder about caching. render.com does some build caching, but doesn't allow us the set custom cache folders (please upvote 🙂). The logs also suggest Next.js doesn't have its build cached. I don't see at the many opportunities for improvement.
bytasv
apedroferreira
Duplicates
Latest version
Summary 💡
With a slowing growing CI running times we might want to look into what's taking how long and whether there are any small wins that we could capture.
Would be good to understand better how long what part of job takes, what are the options to reduce duration (if any), if we could maybe skip CI jobs when they are obviously not required (i.e. change of readme file or something similar that would not benefit in any way from testing or building)
Examples 🌈
No response
Motivation 🔦
No response