|
||||||||
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 |
- [JIRA] (JENKINS-16376) BuildStepMonitor.BUI... fredrik.jo...@gmail.com (JIRA)
- [JIRA] (JENKINS-16376) BuildStepMonito... slide.o....@gmail.com (JIRA)
- [JIRA] (JENKINS-16376) BuildStepMonito... slide.o....@gmail.com (JIRA)
- [JIRA] (JENKINS-16376) BuildStepMonito... scm_issue_l...@java.net (JIRA)
- [JIRA] (JENKINS-16376) BuildStepMonito... slide.o....@gmail.com (JIRA)
- [JIRA] (JENKINS-16376) BuildStepMonito... ku...@gmx.de (JIRA)
- [JIRA] (JENKINS-16376) BuildStepMonito... ku...@gmx.de (JIRA)
- [JIRA] (JENKINS-16376) BuildStepMonito... slide.o....@gmail.com (JIRA)
- [JIRA] (JENKINS-16376) BuildStepMonito... slide.o....@gmail.com (JIRA)
- [JIRA] (JENKINS-16376) BuildStepMonito... slide.o....@gmail.com (JIRA)
- [JIRA] (JENKINS-16376) BuildStepMonito... in...@vaultive.com (JIRA)
- [JIRA] (JENKINS-16376) BuildStepMonito... slide.o....@gmail.com (JIRA)
What we could do is:
check if we have a trigger which needs the previous build's result (fixed, still xyz) and only then require BuildStepMonitor.BUILD.
But I'm not sure if this would be worth the effort and not being more unintuitive to use.