Ability to define global retries strategy for all actions

[tsurdilo]

What would you like to be added:
Global retries strategy that should be applied to all actions
Why is this needed:
Currently each action has to define own

[manick02]

I will take a look at this and come back with questions if any.

[manick02]

I am assuming the global retry strategy means global retries
"autoRetries": { "type": "boolean", "default": false, "description": "If set to true, actions should automatically be retried on unchecked errors. Default is false" }, "retries": { "$ref": "retries.json#/retries" },
In my analysis the best way to do this would be to add one of(globalRetryRef as not mandatory property of type String, or add globalRetry of type #/definitions/retrydef) at the same level in the specification as quoted above. Please correct me if I am wrong in understanding the feature.

[tsurdilo]

@manick02 currently we can define the

  "retries": []

array as a top-level workflow property. in action definitions we can then specify a "retryRef" which maps to one of those retries definitions.
The idea is to somehow define one retries definition which is default, meaning that if an action does not specify a retryRef, this default one should be used.

One idea would be as you mentioned to add a globalRetryRef, another idea could be to add
like a "isDefault" option on retries definition (only one should be set to true), and then it should be used for all action retries for actions that dont explicitly define a retryRef.

Note that currently, if "autoRetries" is set to true, actions that don't set a retryRef are meant to retry forever (up until the action timeout and if not specified up to the workflow execution timeout)
That functionality should remain the same (unchanged)

@cdavernas @ricardozanini wdyt?

[manick02]

In my opinion, Having IsDefault on retries and restricting to only one set to try will make it harder/impossible to describe in the specification using json schema.

[tsurdilo]

agree, some times we cannot just rely on json schema as it does have these types of restrictions. it is ok to define some rules in the spec that go beyond the capabilities of the underlying schema. we can discuss

[manick02]

IMO having rules going beyond schema will implementation of Runtime and TCK bit more complex

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.