|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
I guess your experience of "AccuRev support of their software" differs from my own. My opinions on this subject are not repeatable in polite company. We logged bugs; we showed proof. Then we gave up waiting and I made changes to the Jenkins-accurev plugin until it worked well enough that we weren't getting random builds failures several times a day.
I'm not suggesting that one should re-issue the "accurev info" command before every command.
As you rightly point out, the performance hit would be quite awful, and it wouldn't fix the problem either (as the login can expire spontaneously without warning, e.g. after the accurev info command has run and declared that you're logged in - once upon a time, I had Wireshark/ProcessMonitor/Console logs demonstrating this).
What I am suggesting is that the code should detect when an accurev command fails and then, instead of just blindly declaring the entire build have failed (as it does now), it should examine the output of the command to see if it was an authentication problem, and if it was an authentication problem then it should re-run the "login if necessary" logic before re-retrying the command.
I had hoped that my final paragraph of the original bug report had made this clear.