By default, boardwalk will always retry hosts that have started a Workflow but never finished, regardless of the result of Job preconditions checks. It was designed this way because for most cases it's a reasonable assumption that if a Workflow started one would want it to finish. However, there certain Workflows where this behavior is undesirable, and Job preconditions should be enforced even if a host was not able to successfully complete a Workflow.
This change introduces a new class, WorkflowConfig, with an option to disable this behavior, along with a new method to the Workflow class, .config().
I've done this by introducing a new class, because my thinking is this is a configuration option that would always be used along with a given Workflow. I had considered adding the new option under a WorkspaceConfig object, but unlike the options already available in WorkspaceConfig, this new option isn't something that I expect users would want to configure Workspace by Workspace and instead would be common to all usage of a particular Workflow.
The reason why the WorkflowConfig is to be specified by users with a method, rather than as an attribute, is for consistency. Boardwalk's python API is designed to be friendly to new python users by using repeatable patters that are easy to replicate.
How was this tested?
Tested locally by manipulating a WorkflowConfig and Job preconditions in the ShouldFailTestWorkspace to see if it behaved as expected.
Checklist
[x] Have you updated the VERSION file (if applicable)?
What and why?
By default, boardwalk will always retry hosts that have started a Workflow but never finished, regardless of the result of Job preconditions checks. It was designed this way because for most cases it's a reasonable assumption that if a Workflow started one would want it to finish. However, there certain Workflows where this behavior is undesirable, and Job preconditions should be enforced even if a host was not able to successfully complete a Workflow.
This change introduces a new class, WorkflowConfig, with an option to disable this behavior, along with a new method to the Workflow class, .config().
I've done this by introducing a new class, because my thinking is this is a configuration option that would always be used along with a given Workflow. I had considered adding the new option under a WorkspaceConfig object, but unlike the options already available in WorkspaceConfig, this new option isn't something that I expect users would want to configure Workspace by Workspace and instead would be common to all usage of a particular Workflow.
The reason why the WorkflowConfig is to be specified by users with a method, rather than as an attribute, is for consistency. Boardwalk's python API is designed to be friendly to new python users by using repeatable patters that are easy to replicate.
How was this tested?
Tested locally by manipulating a WorkflowConfig and Job preconditions in the ShouldFailTestWorkspace to see if it behaved as expected.
Checklist