We have some custom function tasks that trigger the start of a process on a third-party tool (e.g. Jenkins, IBM Urban Code Deploy) asynchronously. The id of the started process will be stored in an output or script variable. Then we schedule another step, which checks every 10 seconds, if the process is still in progress. If we get a problem during the verification (e.g. the connection gets reset) the task fails although the process on the third-party tool is still executing.
On retry we would like to check first, if the process is still running before we start a new process. But currently the script variables as well as the output variables are reset on retry and we don't have the old process id available anymore.
For this reason we would like to have an option that allows to define, if the script and/or output variable should be reset on retry or not.
by: Roland F. | over a year ago | Deployments
Comments
Roland, thank you for the idea.
We have seen this request in the past, and it is something that we are planning for the release in October, 2023.
During the refinement with team, we would like to understand is there anything in particular that you would like us to focus on as we consider the configuration of this feature?
For example, are there specific tasks or use cases where you think it would be particularly useful to have this feature customized at the task level rather than at the system level?
As one of the other people who has requested this item, I'm not sure that our use cases care too much if the feature is customizable at the task level vs. the system level. I am not aware of any use cases where having it at the system level would be harmful.
However, could you clarify if you mean it would be customized for task types or for individual tasks? For example, is your thought that two separate use cases of a `remoteScript.Unix` task type could individually specify whether the output variables are saved on a failure? Or that all tasks of type `remoteScript.Unix` would either save or not save, depending on a configuration?
If the customization is at the task instance level, that would potentially be beneficial. But if the customization is an all-or-nothing per task type, I do not believe that would be useful to us vs. a global setting that is all-or-nothing.
Thanks, Peter for the feedback. We are waiting for Roland and his team to comment.
Our team decided to implement system level configuration ad then we could see whether there is any demand or use cases for other configuration types.
Hi Migle,
I'm not sure if there will be any use case where it could be a benefit if the variables a reset on retry. Therefore I've asked my colleagues and they also think that it could be a system-wide setting.
This change is available in June 2023 Early Access release, release notes: https://docs.digital.ai/bundle/devops-release-version-v.23.1/page/release/release-notes/early-access-release.html .