This is an IBM Automation portal for Cloud Platform products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
See this idea on ideas.ibm.com
System: uDeploy
Actor: uDeploy DevOps automation user
Product uDeploy is used for DevOps deployment automation for various technologies.
Description: Our team uses uDeploy for deployment automation as part of DevOps process. However, we have a scenario where sometimes a step takes more than standard time
for completion. Sometimes, the step executes infinitely and one has to manually cancel the deployment. We expect that such step should fail after specifying certain threshold time value i.e. a timeout option should be present for step to fail on its own.
Example: While executing RQM/RFT test cases sometimes an issue occurs with the connectivity and the step goes in infinite status. At this point, we expect the step to fail when it exceeds execution time of more
than 15 minutes since we know it will not take that much time.
We want a option in a step to specify a timeout value so that step should fail automatically after it reaches the timeout value. It will help us to remove manual interventions
and improve productivity.
By clicking the "Post Comment" or "Submit Idea" button, you are agreeing to the IBM Ideas Portal Terms of Use.
Do not place IBM confidential, company confidential, or personal information into any field.
Each plugin needs to implement its own timeout setting. This cannot be done by the server itself. Please create an RFE/IDEA for the specific plugin you need.
Although the theme of this request is consistent with our business strategy, it is not committed to the release that is currently under development.
Thank you for the update.
Yes, adding timeout field in RQM/RFT plugin will definitely help us to overcome this problem faced in most of the applications. Please proceed with this at the earliest. If the steps gets timeout then the end result should be failure.
In future as Chris has mentioned we would love to see timeout field as configuration parameter in components/generic process available in uDeploy.
Please let me know in case of queries.
This request lacks sufficient information for us to evaluate it. It might not be considered further until it has been revised and clarified. Would you prefer to have, as a workaround, a timeout field added to the RQM/RFT plugins? We could deliver the plugin updates more quickly than adding a timeout to all steps.
I didn't open this RFE, but I am interested in it. My opinion is that a step timeout should result in a failure of that step.
This is something I have always wished for in UCD as well. I would love to see the ability to set a step timeout default as a configuration parameter for the component/generic process, and then at the individual step level, a timeout field as well, which would include a "no timeout" option for process steps that have a default timeout, but where a particular step should never timeout.
If a timeout threshold should be exceeded on the RQM/RFT step, what is your expected outcome of the deployment - success or failure?
Should anyone be notified when this particular use case happens?
If a timeout threshold should be exceeded on the RQM/RFT step, what is your expected outcome of the deployment - success or failure?
Should anyone be notified when this particular use case happens?