Feature #2939

Workbench button to re-run a past job.

Added by Peter Amstutz over 6 years ago. Updated over 6 years ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
-
Start date:
05/30/2014
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
Story points:
0.5

Description

This requires adding to ArvadosBase a way to propagate parameters (other than attributes of the new model) to the "create" API call. Perhaps like f8d20973


Subtasks

Task #2941: Review 2939-re-run-job-buttonResolvedPeter Amstutz

Task #2942: Add buttons to re-run the current job to job status pageResolvedPeter Amstutz

Associated revisions

Revision e881778a
Added by Peter Amstutz over 6 years ago

Merge remote-tracking branch 'origin/master' into origin-2939-re-run-job-button refs #2939

Conflicts:
services/api/db/schema.rb

Revision cda441b1
Added by Peter Amstutz over 6 years ago

Merge remote-tracking branch 'origin/master' into origin-2939-re-run-job-button refs #2939

Conflicts:
services/api/db/schema.rb

Revision 7e865395 (diff)
Added by Peter Amstutz over 6 years ago

Fix for running workbench against server that doesn't have 'Job.supplied_script_version' yet. refs #2939

History

#1 Updated by Tom Clegg over 6 years ago

  • Description updated (diff)

#2 Updated by Peter Amstutz over 6 years ago

  • Assigned To set to Peter Amstutz

#3 Updated by Radhika Chippada over 6 years ago

Review comments:

1. Can we use the label "Re-run job using script version:" instead of "Re-run job using version:"?

2. Instead of "Same <uuid>", how about "Same as previous run" or something that conveys the meaning, "same version used for previous run of the job"?

3. Instead of "Latest (repo_name/version), how about simple "Latest version" ?

4. If the version used to run the job before is still the latest version (basically, only one version of the script), do we still want to show both buttons?

5. When I loaded the page the first time, I saw both "Same as" and "Latest" buttons. I, luckily or unluckily, clicked on the "Latest" button first. And I kept seeing the error message "supplied_script_version" does not exist. The error went away when I used the "Same as" button to rerun the job once.

6. When I rerun the jobs using either one of the rerun buttons, the page never refreshes.

7. Migration script: should we be setting the "supplied_script_version" during the migration? Is this why I saw error in 5? Or, may be we just need to handle the error when it is null.

8. jobs > _show_status.html.erb - line 11 and 24 {class: 'btn btn-primary', id: "run-pipeline-button"}
Should it use button id "run-job-button" ?

9. jobs > _show_status.html.erb - line 28
<table class="table pipeline-components-table">
Should it use table name "job-components-table" ?

#4 Updated by Peter Amstutz over 6 years ago

Changes are in branch 2882-job-process-stats per our conversation

  1. Inserted word "script"
  2. Changed text to "Same as this run"
  3. It's sort of awkward to resolve a branch or tag to a commit from workbench, but now it will at least check if script_version and supplied_script_version are the same and hide the second button.
  4. Fixed so that it does not show the second button when "supplied_script_version" is null or empty
  5. Fixed, adds a "Cancel" button when the job is actually running.
  6. I'm going to address refreshing in another branch.
  7. See above. We could copy script_version into supplied_script_version as part of the migration, otherwise that information isn't available (which is why I had to add a new column)
  8. Fixed button id names
  9. That's a style, I didn't want to rename the style, so I left it.

#5 Updated by Peter Amstutz over 6 years ago

  • Status changed from New to Resolved

Also available in: Atom PDF