|
||||||||
|
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 jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Can you explain further what you would propose as a solution to the problem?
As far as I can tell, if jobs are configured to listen to poll on the notifyCommit, and the SHA1 passed as a parameter is part of the notifyCommit, then that SHA1 should be built, if it is available in the repository. That seems like "do the work I requested" rather than "denial of service". I don't see a significant difference between an arbitrary SHA1 and a change on the master.
Would it be better to have a global switch in Jenkins which allows the Jenkins core to ignore the value passed as sha1? Administrators concerned about users invoking jobs with arbitrary SHA1 values could then ignore that value, accepting that by ignoring the value from some users, they must ignore it from all users.
Would it be better to have a global switch which requires that if there is a sha1 value, then there must also be a branch value, otherwise the request is ignored?
Alternately, if the passed SHA1 is the same as the preceding SHA1, it might be possible to ignore the request (since the preceding build was the same SHA1, the git plugin generally assumes the same SHA1 does not need to be built twice).
Also, can you clarify if there is any significance to the "without branch name" portion of the report? When I insert branch=master as another URL argument, I believe I see the same result, that all jobs for repositories seem to launch all the jobs as well.