Speeding up CI builds

Development
1

Hey,

I haven’t tried this before but I was thinking of ways to speed up builds of foreman and other projects I work on. CI builds take a long time just to download gems and I think we can easily improve this. Basically my idea is the following:

  1. create a simple task to use bundle package on a repo like foreman and then tar up the cache directory and place giant tar file on S3 or somewhere else.
  2. Perform a download of this tarball and extract to the vendor/cache directory during CI job
  3. run bundle install (uses cache directory instead of ruby gems.org)
  4. run rake test

Docs for using bundler packages

http://bundler.io/v1.2/bundle_package.html <http://bundler.io/v1.2/bundle_package.html>

Now we could make this go even faster by storing the entire gemset package with all the compiled gems in a tar but it would be OS specific at this point and would need to provide many
os specific versions in a similar manner.

I am not sure what you guys are doing on your jenkins server but it sure would be nice to have this on travis.

It just seems silly to download the same things over and over and sometimes this takes 10-15 minutes. Additionally, I have seem some tests fail because one gem didn’t download correctly.

thoughts? Sounds pretty easy to implement, with the exception of who’s S3 account to store them on.

Corey

2

> Hey,
>
> I haven’t tried this before but I was thinking of ways to speed up
> builds of foreman and other projects I work on. CI builds take a long
> time just to download gems and I think we can easily improve this.
> Basically my idea is the following:
>
> 1. create a simple task to use bundle package on a repo like foreman and
> then tar up the cache directory and place giant tar file on S3 or
> somewhere else.
> 2. Perform a download of this tarball and extract to the vendor/cache
> directory during CI job
> 3. run bundle install (uses cache directory instead of ruby gems.org
> <http://gems.org>)

Probably bundle update too, so it's fully up to date.

> 4. run rake test
>
> Docs for using bundler packages
>
> http://bundler.io/v1.2/bundle_package.html
>
>
> Now we could make this go even faster by storing the entire gemset
> package with all the compiled gems in a tar but it would be OS specific
> at this point and would need to provide many
> os specific versions in a similar manner.
>
> I am not sure what you guys are doing on your jenkins server but it sure
> would be nice to have this on travis.

Travis recently added this feature, though it's not enabled by default:
http://docs.travis-ci.com/user/caching/

I was looking to enable it on our installer modules recently, but had to
fix a few bugs in other projects to exclude the vendor/ directory that
Travis then configures Bundler to use.
(https://github.com/puppetlabs/puppetlabs_spec_helper/pull/86)

Regarding our Jenkins setup, we use rvm gemsets heavily - each job
creates a uniquely named gemset, installs bundler, runs bundle install
and then deletes it again after.

> It just seems silly to download the same things over and over and
> sometimes this takes 10-15 minutes. Additionally, I have seem some
> tests fail because one gem didn’t download correctly.
>
>
> thoughts? Sounds pretty easy to implement, with the exception of who’s
> S3 account to store them on.

Yeah, I've thought about doing something similar, but wasn't sure on the
implementation and I'm slightly wary of over-complicating our infra
setup. We did move to using parallel bundler installs and SSD slaves
which greatly sped up installation, though it still takes 2-3 mins.

We could simply change how we use gemsets and keep them around - use one
per executor, rather than one per job, so gems remain installed into the
gemset and when we run bundle install, many will already be there.

··· On 11/02/15 06:32, Corey Osman wrote:

–
Dominic Cleal
Red Hat Engineering