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

Streamline Travis CI builds to avoid "Killed" messages

    Details

    • Type: Task
    • Status: Closed (View Workflow)
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
    • Attachments:
      0
    • Comments:
      2
    • Documentation Status:
      Not Required

      Description

      Occasionally we still see random "Killed" messages in our Travis CI builds. After contacting Travis staff, they noted we are occasionally bumping up against their 3GB memory limit. Whenever you pass that 3GB limit, Travis automatically kills your build/test process. See this FAQ for more:

      http://docs.travis-ci.com/user/common-build-problems/#My-build-script-is-killed-without-any-error

      Usually, thus far, simply manually restarting the build has worked fine when we encounter these "Killed" messages. But, we don't want to have to continue to do that.

      Some suggestions from Travis staff:

      1) We may want to run "free -m" or "cat /proc/meminfo" between steps of our build process so that we can see which step(s) are actually using a lot of memory. That way we narrow down the problem step(s) and work to streamline them.

      (2) It's also possible to stop any automatic services that spin up on Travis servers. We can run 'ps aux' as part of the Travis build (in the "before_script" section) to see what services are running and explicitly stop any that we don't need (again in "before_script" section) in order to maximize our memory.

      Personally, I suspect the cause is that we are building and testing 13+ maven modules all at once. Each time we add a new module (e.g. with both Mirage2 and 'dspace-rdf'), we've seen these "Killed" messages reappear.

      We might be able to streamline by building & testing the modules in "batches", followed at the end by a "quick build" assembly of all of DSpace. But, the tips from Travis staff might be a good starting point to narrow down the problem.

      Needs a volunteer to investigate.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              tdonohue Tim Donohue
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: