NOTICE! This is a static HTML version of a legacy ImageJ Trac ticket.

The ImageJ project now uses GitHub Issues for issue tracking.

Please file all new issues there.

Ticket #1860 (closed enhancement: fixed)

Opened 2013-05-10T12:58:46-05:00

Last modified 2013-05-31T16:16:40-05:00

Add a Jenkins job for monitoring the disk usage on

Reported by: dscho Owned by: dscho
Priority: major Milestone: imagej2-b7-ndim-data
Component: Server Admin Version:
Severity: serious Keywords:
Cc: curtis Blocked By: #1862
Blocking: #1857


For the moment, shares disk space with, and in any case, users of will share disk space with each other. To prevent abuse (and thereby denying other users the space), let's monitor the disk usage using Jenkins.

Change History

comment:1 Changed 2013-05-10T12:59:59-05:00 by dscho

My original plan was to do it via quotas, but quotas are only per-user and per-filesystem, not per-directory. Since the same "user" (i.e. www-data) owns all the files, quotas are pretty useless here.

comment:2 Changed 2013-05-10T15:00:10-05:00 by dscho

  • Blocked By 1862 added

comment:3 Changed 2013-05-12T10:16:22-05:00 by dscho

  • Status changed from new to closed
  • Resolution set to fixed

comment:4 Changed 2013-05-12T10:35:32-05:00 by dscho

Forgot to mention: to be able to mark the build as unstable when a soft quota is reached, or when unexpected files were found, I also copied jenkins-cli.jar into ~jenkins/bin/ and added a private key.

comment:5 Changed 2013-05-13T09:59:28-05:00 by curtis

So if I understand correctly, Jenkins is running a script which calls jenkins-cli to change Jenkins state? Wouldn't it be simpler to use Groovy postbuild to set the build to unstable that way?

(I took a very quick look at the job to find out the answer for myself, but it is quite complex, with a long shell script embedded in the job, so I am punting with this comment instead.)

comment:6 Changed 2013-05-13T11:09:55-05:00 by dscho

Jenkins runs the shell script on the node (and thus has easy access to the files generated by said script), but runs the postbuild on the master (which does not).

Actually, in our case, I archive the files so the postbuild *could* access the files and read them and analyze them, but I think doing that would be more fragile (and also would require more code to begin with, as shell is *still* more expressive than Groovy).

comment:7 Changed 2013-05-13T11:12:55-05:00 by curtis

OK, thanks, that makes sense. The current approach sounds fine then. Another possibility would be to change the shell script to do the analysis, but rather than using jenkins-cli to mark the build as unstable, instead write out a file RESULT with e.g. "Success" or "Unstable" or "Failure" as its contents, then have the Groovy postbuild use that to decide. But I don't feel strongly about it.

comment:8 Changed 2013-05-31T16:16:40-05:00 by bdezonia

  • Milestone changed from imagej2-b8-analysis to imagej2-b7-ndim-data