I don't know how difficult it is (CPU intense for Jenkins?) to recalculate the quality gates for all following builds up to the last build, but from a user point of view: As soon as the pipeline measures more issues because a new tool is detected used by the git repository then it is quite possible that the defined quality gate will always fail. This is a gap in the plugin. It is not possible to define tool-specific quality gates (new feature!) but apart from that image a project which needs a little bit more flexibility and then a PO comes along and says that is also good enough that is our baseline for now. But on a develop branch the developer push quickly. So choosing the last one would be maybe not right one. Why not choosing the first unstable / failed one after the latest successful build? Also I'd like to know if the "reset quality gate" button could be restricted to certain user/group configurable via Jenkins access control? |