5 ms·

Faster Builds with Container-Based Infrastructure and Docker

70 points by aseidl 12y ago

preillyme 12y ago
Wow this really is only the beginning of you offering better, faster and more reliable builds on Travis CI. You seem to have a lot more things planned to improve stability, I'm totally excited that you shipped this today.
GolfyMcG 12y ago
I already liked some of the UI updates I was seeing on Travis yesterday - this sounds like it could solve some of my (few) issues with Travis' consistency and speed! Excited to dig in further. E1: Removed incorrect possessive form of Travis.
jakozaur 12y ago
That's a great news. I see ppl setup their own CI, b/c they need some custom stuff. With Travis CI supporting docker, it is way easier to do that with them.
- koffiezet 12y ago
  At the moment it will be harder, since granting someone root-access in a container is pretty dangerous, containers are not very good for security (yet). If you read the article, they state that using custom images is not yet possible.
aseidl 12y ago
Some rough numbers: bundle install has gone from ~50s to 3s for my Jekyll + s3_website setup. The overall build has dropped from ~120s to 45s thanks to that and using a cached version of Ruby. One gotcha for anyone with a similar setup: make sure Jekyll's _config.yml is set to exclude/ignore the vendor directory. Oops.
- rb2k_ 12y ago
  Are you sure those speedups are docker related, those sound like they're bundler/caching related? ( as in http://docs.travis-ci.com/user/caching/ http://docs.travis-ci.com/user/caching/ )
  - aseidl 12y ago
    Correct, the speedups are directly due to bundle caching (which previously had only been available for private/paid repos). Indirectly, I would assume this caching is now implemented via Docker's use of filesystem layers.
deleted 12y ago
[deleted]
hunt 12y ago
This is exciting news - it's a shame that sudo isn't supported in the Travis-CI Docker containers (is this common for all Docker containers?). Uploading binaries to S3 and then downloading them to use in the build process seems like a total faff - I use Travis-CI to avoid that kind of hassle...

70 points by aseidl 12y ago

Wow this really is only the beginning of you offering better, faster and more reliable builds on Travis CI. You seem to have a lot more things planned to improve stability, I'm totally excited that you shipped this today.

GolfyMcG 12y ago

I already liked some of the UI updates I was seeing on Travis yesterday - this sounds like it could solve some of my (few) issues with Travis' consistency and speed! Excited to dig in further. E1: Removed incorrect possessive form of Travis.

jakozaur 12y ago

That's a great news. I see ppl setup their own CI, b/c they need some custom stuff. With Travis CI supporting docker, it is way easier to do that with them.

koffiezet 12y ago
At the moment it will be harder, since granting someone root-access in a container is pretty dangerous, containers are not very good for security (yet). If you read the article, they state that using custom images is not yet possible.

aseidl 12y ago

Some rough numbers: bundle install has gone from ~50s to 3s for my Jekyll + s3_website setup. The overall build has dropped from ~120s to 45s thanks to that and using a cached version of Ruby. One gotcha for anyone with a similar setup: make sure Jekyll's _config.yml is set to exclude/ignore the vendor directory. Oops.

rb2k_ 12y ago
Are you sure those speedups are docker related, those sound like they're bundler/caching related? ( as in http://docs.travis-ci.com/user/caching/ http://docs.travis-ci.com/user/caching/ )
- aseidl 12y ago
  Correct, the speedups are directly due to bundle caching (which previously had only been available for private/paid repos). Indirectly, I would assume this caching is now implemented via Docker's use of filesystem layers.

deleted 12y ago

[deleted]

hunt 12y ago

This is exciting news - it's a shame that sudo isn't supported in the Travis-CI Docker containers (is this common for all Docker containers?). Uploading binaries to S3 and then downloading them to use in the build process seems like a total faff - I use Travis-CI to avoid that kind of hassle...