-
-
Notifications
You must be signed in to change notification settings - Fork 11
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
feat(ui): allow resending of webhooks to update deployed version #110
feat(ui): allow resending of webhooks to update deployed version #110
Conversation
1ccbdd6
to
29710c8
Compare
also restrict retry frequency #102
8762a80
to
808fb44
Compare
block repeats whilst running/sending block runs whilst under `delay` with `auto_approve`
808fb44
to
8d96400
Compare
Codecov Report
@@ Coverage Diff @@
## master #110 +/- ##
==========================================
+ Coverage 95.59% 95.69% +0.10%
==========================================
Files 49 49
Lines 4419 4517 +98
==========================================
+ Hits 4224 4322 +98
Misses 148 148
Partials 47 47
Continue to review full report at Codecov.
|
bf379a7
to
8d96400
Compare
9525a49
to
ceaeece
Compare
* faq detailing how to change the retry block time release-argus/Argus#110 * info for the new sqlite db release-argus/Argus#113
requested in #102
resend availability for upgrades to newer LatestVersion. Have added minimum delays to these sends of 15s if they fail and 2xInterval of the Service if they pass. Users could change their browser times to get around the disabled buttons, but the server keeps track of the next runnable time and ignores the request if it's too early. We could still get situations where two users approve commands/webhooks before they find out that another user did the same. In this case, if the delay between these requests is big enough that the goroutines have synced the next runnable time, then only one request will be made, but if the goroutines haven't been synched yet, the webhooks/commands could be actioned twice. If people want, I could look into mutex locks to account for this possibility, but I feel that this isn't really a risk and so not worth further investigation.
normal modal:
![](https://user-images.githubusercontent.com/4267227/178157629-ad61c2dc-e5f8-447b-a14b-29bacfb547c9.png)
![](https://user-images.githubusercontent.com/4267227/178157641-5382ebfa-6345-4836-b4ef-72b2a90de2d0.png)
![](https://user-images.githubusercontent.com/4267227/178157641-5382ebfa-6345-4836-b4ef-72b2a90de2d0.png=250x250)
command fails (same for webhooks):
after 15s:
![](https://user-images.githubusercontent.com/4267227/178157737-cdeb1465-eda6-481f-aa0c-2d09926596d3.png)
successful command/webhook:
![](https://user-images.githubusercontent.com/4267227/178157872-1678a05e-9a8f-4b5a-9fe3-995975606623.png)
resendable after 2xInterval