We need more CI processes using https://bazel.build
Ask HN: How Long Is Your CI Process?
11–20 of 81 posts
Re: Ask HN: How Long Is Your CI Process?
#12Hard to say without knowing /what/ you want to accomplish in your CI process, so maybe some open source examples will help:
* A "complex" library (node-resque). In CI (CircleCI) we install deps, compile Typescript to JS, test on 3 versions of node, and build docs. 4 min w/ some parallelization https://app.circleci.com/pipelines/github/actionhero/node-re...
* A web server framework (actionhero): In CI(Github Actions) we install deps, compile Typescript to JS, test on 3 versions of node, and build docs. 7 min w/ some parallelization https://github.com/actionhero/actionhero/actions/runs/801273...
* A Monorepo (Grouparoo): In CI (CircleCI) we install deps, compile Typescript to JS, run migrations, check licenses, test UIs, CLI tools, Plugins, and try out a few different databases. 5 minutes with rather extreme parallelization https://app.circleci.com/pipelines/github/grouparoo/grouparo...
In my experience, the biggest wins in CI speed improvements come from parallelization. You can parallelize by either running multiple processes/containers or by running tests in parallel on the same container (jest, parallel_tests, etc)
Re: Ask HN: How Long Is Your CI Process?
#13I like how many people responded but didn’t answer your question.
Re: Ask HN: How Long Is Your CI Process?
#14For the kinds of projects you mention (scripting language, small-medium sized) I aim for 1-2 minutes max, which is usually not a problem. This precludes running a lot of integration tests requiring expensive setup/teardown, though the need or value of those greatly depends on the project.
Re: Ask HN: How Long Is Your CI Process?
#15Between 30 seconds and about 45 minutes.
The only times when it was long enough that it was painful it was because there was a stage that couldn't be debugged without running the build. That's invariably what I actually preferred to fix, not the total lead time.
A 45 minute sanity check to verify nothing is fucked before releasing is fine. A 45 minute debugging feedback loop is a nightmare.
Faster CI builds are typically a nice-to-have rather than a critical improvement (& doing too many nice to haves has killed many a project).
Re: Ask HN: How Long Is Your CI Process?
#162 minutes and 7 seconds https://github.com/jart/cosmopolitan/runs/2482398460 on travis for a repository that builds 14,479 objects, 67 libraries, and 456 static executables, 284 of which are test executables which are run too. If I want to run all the test binaries on freebsd openbsd netbsd rhel7 rhel5 xnu win7 win10 too, then it takes 15 additional seconds. On a real PC, building and testing everything from scratch…
This is absolutely ridiculous in the best possible way
Re: Ask HN: How Long Is Your CI Process?
#17At my current job, the full build/test/release cycle is about 45 minutes. There is an effort to begin optimizing it but it is a high risk endeavor that only became worth it once the costs started growing faster than our team size and became unsustainable.
CI tech debt is very difficult to pay down, and imho not worth it unless the dollar costs are becoming excessive and you have a dedicated release or DevOps engineer who can own it as an internal product.
Re: Ask HN: How Long Is Your CI Process?
#18Several hours, which is far too long. It's a massive waste of developer time and money, but try explaining to diverse contributors ("features features features!") that some investment in the testing setup would save money in the long run...
Re: Ask HN: How Long Is Your CI Process?
#19We have a CI pipeline for a containerized python app and a react app. We have a monorepo and only trigger certain jobs depending on code changes. Our CI runs through Gitlab CI on a GKE cluster, which gives us a lot of control over the parallelism and the resources allocated.
Our pipeline typically takes 10-30 minutes, depending on what jobs run and where cache gets used.
The longest job, at a consistent 12 minutes is our backend test job. There’s not a lot we can do to speed this up any further because a lot of the tests run agains a test db so we can’t easily run them in parallel. Perhaps if we wanted to be really clever we could use multiple test dbs.
The build for our containers is usually very quick (a few minutes) unless we modify our package requirements.txt. That happens infrequently but it triggers an install step that will increase the overall time for the job to 10-12 minutes.
The deploy phase is very quick.
We spent a bit of time optimizing this and it came down mostly to:
1. Using cache where we can.
2. Ensuring we had enough resources allocated so that jobs were not waiting or getting slowed down by lack of available cpu.
2. Making sure that each command we run is executing optimally for performance. Some commands have flags that can speed things up, or there alternate utilities that do the same thing faster. One example of the latter is that we were using pytype as our type checker, but it often took about 15 minutes to run. We swapped it out for pyright, which takes under 5.
Re: Ask HN: How Long Is Your CI Process?
#2030 minutes? I don't have exact numbers, but I know ours is under 10 minutes and IMO that is not optimized at all. Maybe 30 minutes is okay for a very large project, but for most applications that seems quite high to me.
Our pipeline runs in Jenkins and builds a docker image that runs composer installs, application copy, and that sort of thing. We also run phpunit, phpstan, phpmd, and phpcs in our pipeline. Finally the image gets pushed up to ECR.
I think that's all pretty standard stuff. TBH I'd like us to move to github actions and optimize for more staged builds in our docker images, but we have higher priorities at the moment.