PROJECT: Implement web application for testing commit ranges #5BRL-CAD
Status: ClosedTime to complete: 100 hrs Mentors: Popescu Andrei, Daniel_RTags: code, web, python, javascript, php, ruby

This task is part of a larger project with several follow-on tasks. Search on the title and read their descriptions to find related tasks.

We very often end up writing scripts that iterate over on a range of commits to our repository. We usually do this to find when a bug was introduced or evaluate some impact over time (e.g., performance).

This step has you hook up the front-end to actually manage jobs. Basically, provide a means for editing the job queue to pause/continue, cancel, or reorder jobs. Basically, these should probably exist as status subdirectories with job subdirectories within them on the server. Making changes to a job in the web interface then merely needs to move a job subdirectory from one status subdir to another.

Uploaded Work
File name/URLFile sizeDate submitted
commit-range-tester-job-control.tar.gz5.2 KBJanuary 18 2015 08:34 UTC
Comments
tejason January 12 2015 09:02 UTCTask Claimed

I would like to work on this task.

Daniel_R on January 12 2015 09:06 UTCTask Assigned

This task has been assigned to tejas. You have 100 hours to complete this task, good luck!

Melange on January 16 2015 13:06 UTCTask Reopened

Melange has detected that the final deadline has passed and it has reopened the task.

Andromeda Galaxyon January 18 2015 04:25 UTCTask Claimed

I would like to work on this task.

Sean on January 18 2015 04:26 UTCTask Assigned

This task has been assigned to Andromeda Galaxy. You have 36 hours to complete this task, good luck!

Andromeda Galaxyon January 18 2015 08:39 UTCStatus

This patch (along with the associated updated scripts) makes it possible for jobs to be in multiple different states per execution class.  Currently, this allows running scripts to be paused (a paused script will not be run until it has been unpaused and there are few enough jobs running that starting it wouldn't violate the MAX_RUNNING_JOBS limit) and queued jobs to be suspended (a suspended script will not be moved to the running state until unsuspended).  In the future, the same mechanisms could be used to support states such as "waiting for " to ensure that a specific script does not run until after another, providing a form of reordering; however, getting this infrastructure into place took a large amount of time (~4hrs) and this set of operations provides basic reordering through pausing/suspending and then later resuming relevant jobs, so I decided to leave it out for now.

Andromeda Galaxyon January 18 2015 08:39 UTCReady for review

The work on this task is ready to be reviewed.

Popescu Andrei on January 18 2015 08:51 UTCTask Closed

Congratulations, this task has been completed successfully.