Uploaded image for project: 'DSpace'
  1. DSpace
  2. DS-2628

using the new container-based infrastructure on Travis-CI


    • Attachments:
    • Comments:
    • Documentation Status:
      Not Required


      DSpace currently uses Travis-CI as the only solution for automated building and testing (after our self-hosted Bamboo server was discontinued). Travis-CI has been traditionally offering builds in a VM environment created on-demand, but is now gradually transferring to a container-based approach which will help them scale by allocating resources more efficiently.


      Switching builds to the new infrastructure is easy, just adding one line to .travis.yml:
      sudo: false

      The only immediate benefit for DSpace is that the build starts immediately because container start-up is much quicker than VM start-up. I've run a couple of dumy builds of the master branch to test the stability and build times. While the build times seem to be a bit lower than before, this is a big YMMV and should not be a factor in our decision to move (due to changes in load both within a single day and as more users transfer to Travis containers).

      See my builds in the test-travis-containers branch:

      The only negative aspect is inability to use sudo, which we currently don't use in our build process.

      There is a potential benefit that this gives us the option to use dependency caching, but for Java projects this is not an out-of-the-box option. We might be able to use caching for Ruby gems within Mirage 2.

      Overall, I see two reasons why we should move:
      1) this is the future for Travis, so we may jump in early to make sure we're not affected by any bugs it brings.
      2) we'll get 4 GB of RAM instead of 3 GB (our builds are occasionally being killed for exceeding 3 GB)




            • Assignee:
              tdonohue Tim Donohue
              helix84 Ivan Masár
            • Votes:
              0 Vote for this issue
              2 Start watching this issue


              • Created: