-
Notifications
You must be signed in to change notification settings - Fork 188
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Run now dialog improvements #977
Conversation
…alog on submit if we're tracking the task
…ow run from request.promptRun rather than each time that function is called.
…ges to the poller that directed to the log tailer to enable this without absurd duplication of code
vex.dialog.prompt | ||
message: "<h3>Run Task</h3>" | ||
message: "<h3>#{if task then 'Rer' else 'R'}un Task</h3>" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nothing wrong with this logically, but for the sake of clarity in the code, maybe:
#{if task then 'Rerun' else 'Run'} Task
$('#filename').val localStorage.getItem('taskRunRedirectFilename') | ||
$('#autoTail').prop 'checked', (localStorage.getItem('taskRunAutoTail') is 'on') | ||
taskRunAfterStart = localStorage.getItem('taskRunAfterStart') | ||
$('#filename').val localStorage.getItem('taskRunRedirectFilename') or 'service.log' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
service.log is a very internal thing for us, if not using our executor the log file will be stdout or some other file. I believe we have this already somewhere, but there should be a configurable default log file we can put here instead
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It remembers your previous choice and puts it in there, so it might be ok to not actually have any default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I got that from the placeholder text, which is currently 'e.g. service.log'. But that's a constant, not configurable atm.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, the configuration exists and is now being used.
<p><label class='label-light'><input id="autoTail" name="autoTail" type="checkbox"> Wait for task to start, then start tailing:</label></p> | ||
<strong>After triggering the run:</strong> | ||
<p> | ||
<label class='label-light'><input id="stay-on-request-page" name="afterStart" type="radio" value="stay-on-request-page"> Stay on this request's page</label> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm going to take out the word "request's" here because the dialog can be accessed from pages other than just a request page.
message: "<h3>#{if task then 'Rerun' else 'Run'} Task</h3>" | ||
input: runTemplate | ||
id: @get "id" | ||
prefix: @localStorageCommandLineInputKeyPrefix |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we still need this prefix if we aren't using localStorage for populating args anymore?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope! It's gone.
…e arg population has been nuked
@trigger 'refreshrequest' | ||
setTimeout ( => @trigger 'refreshrequest'), 2500 | ||
if taskId | ||
task = new TaskHistory {taskId} | ||
task.fetch() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we already have the task history fetched on this page, is there not a way we can use the data we already have?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately, that's not inherently true. While it is true if you're running from the individual request's page, you may also be running the request from the list of requests page, or from the pending tasks page.
Edited to clarify
"#{ config.apiRoot }/history/request/#{ @requestId }/run/#{ @runId }" | ||
else | ||
# Currently the above URL is the ONLY place to fetch this model. | ||
# If you don't have access to request ID and run ID use the TaskHistory |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
once we have the taskId, we can also fetch this using that. I know the main use case with be by runId, but just wanted to clarify
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When you fetch by taskId, you get a different model as a response. That gives back a SingularityTaskHistory (which is the TaskHistory model in the UI), wheras searching by runId returns a SingularityTaskIdHistory (Which is this model in the UI). In a roundabout way, you can use Task Search to search out this model by taskId, but then you'd be fetching the collection rather than the model.
…ssage to tell user to ignore expected http 404 error
…rrect file; Text box for file to tail is disabled, not hidden, when a different box is clicked
…rowse to task sandbox' checked
…e pending tasks page" This reverts commit 857c495. It broke the build
This makes big changes to the run now dialog UX, and even bigger changes behind the scenes to enable this.
UX improvements
Behind the scenes UI changes
Backend change