Add manual run and retry for status updates.
Review Request #11129 — Created Aug. 10, 2020 and submitted
One common request for the status updates feature has been to allow
manual or deferred running of tools. This is desirable for a few
different situations, such as infrequently-run or expensive checkers,
test builds, etc. This change adds the framework for that.The
StatusUpdate
model has a new state,NOT_YET_RUN
, which will show
a button that will trigger the action. This requires that the caller (an
extension) listen to the newstatus_update_request_run
signal to
actually run the tool.Because it is very similar in its implementation, this additionally adds
an ability for the creator of the status update to indicate that it can
be retried. The Retry action will be shown if the status update is
marked as retryable (viaextra_data
), and the result of the status
update is in either error or timeout states. Like the "Run" action,
this requires handling the new signal to actually run the tool when the
user clicks the button.The StatusUpdate API can now accept
request-run
in the state field,
which will trigger the new signal. This allows the frontend (or
third-party callers) to trigger the run/retry action.Based on work by Alex Klemenchuk at /r/10311/
- Ran python and JS unit tests.
- Used in conjunction with a Review Bot change to use these features.
Description | From | Last Updated |
---|---|---|
Col: 15 'localSitePrefix' is defined but never used. |
reviewbot | |
Col: 49 Missing semicolon. |
reviewbot | |
E703 statement ends with a semicolon |
reviewbot | |
E703 statement ends with a semicolon |
reviewbot | |
Can you add: ... Type: bool |
chipx86 | |
Can you add: ... Type: unicode |
chipx86 | |
"ID" |
chipx86 | |
Can you swap these so they'll be in alphabetical order? |
chipx86 | |
Instead of checking if this is in kwargs and then fetching this in two spots, how about pulling it out … |
chipx86 | |
Hmm, we should localize this, though I noticed we don't elsewhere. In standard forms, they're typically localized and have trailing … |
chipx86 | |
Should use assertSpyCalledWith(). |
chipx86 | |
Should use assertSpyCalledWith(). |
chipx86 | |
Should use assertIn(). Though, can we check the explicit value, instead of just the presence? |
chipx86 | |
Same as above. |
chipx86 | |
E703 statement ends with a semicolon |
reviewbot | |
E703 statement ends with a semicolon |
reviewbot |
- Commit:
-
f49e00cbb7d15236c5f720d41a05c10b64424628d0ff77c3bdbd970248e380669b47c865b62fb6a5
- Diff:
-
Revision 2 (+419 -16)
Checks run (2 succeeded)
-
-
-
-
-
-
Instead of checking if this is in
kwargs
and then fetching this in two spots, how about pulling it out first and then checking if it'sNone
before operating on it? -
Hmm, we should localize this, though I noticed we don't elsewhere. In standard forms, they're typically localized and have trailing periods.
Dunno if it's worth doing that in this change, since it's not an isolated case here.
-
-
-
-
- Commit:
-
d0ff77c3bdbd970248e380669b47c865b62fb6a5c60f95da7ce8fd84ad97297e247ef2c3f1fe1d8c
- Diff:
-
Revision 3 (+431 -17)
- Change Summary:
-
Derp.
- Commit:
-
c60f95da7ce8fd84ad97297e247ef2c3f1fe1d8cbaa7313dbd52f9aef4c68ca2af8e05df8ac1096e
- Diff:
-
Revision 4 (+431 -17)