Add retries and retryTimeout option
#20
Conversation
| @@ -1,5 +1,4 @@ | |||
| Sauce Connect Proxy GitHub Action | |||
| ================================= | |||
| # Sauce Connect Proxy GitHub Action | |||
There was a problem hiding this comment.
vscode auto reformatted this file. Can revert the style changes if you like
|
Hmm unfortunately it looks when the limit is reached the file is still written :/ Maybe we’ll have to check the output? Or maybe the ready file contains something useful? |
| saveState('containerId', containerId) | ||
| return | ||
| } catch (e) { | ||
| if (Date.now() - startTime >= retryTimeout) { |
There was a problem hiding this comment.
This means by default there will be no retries, correct?
There was a problem hiding this comment.
Yep I thought we should keep the existing behaviour the same?
There was a problem hiding this comment.
I am wondering if we should enable retries by default. We expect the tunnel to start with the first try so we wouldn't modify the existing behavior anyway. And having the action to retry rather than fail seems to me like an desired feature.
There was a problem hiding this comment.
Ok cool. Do you think 10 minutes would be a good default?
|
I'm thinking in order to catch the concurrent limit error (and possibly others) I might add a connection check step after |
I was using the wrong version of the action 🤦 . Done some testing and the file isn't written, so it works properly :) |
because the log says it can effect performance when enabled
|
@christian-bromann please can you update the dist folder so we can switch back this repo? |
|
@tjenkinson what do you mean by that? |
|
I mean this folder https://github.com/saucelabs/sauce-connect-action/tree/master/dist I didn't run the build as part of the PR so that folder on master is out of date. |
|
Done. Released as |
|
Awesome thanks! |
I haven't tested this yet (but not really sure how), and there aren't any unit tests either. Let me know if you'd like unit tests and I'll add some.
This adds retries, where the delay gets larger each time, and a retry is not scheduled if more than
retryTimeoutseconds has passed. I'm hoping this will be useful when the concurrency limit is reached. When that happens I'm assuming the ready file isn't created?