|
||||||||
|
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/groups/opt_out.
I think you may have misunderstood the result of "Polling ignores commits from certain users".
I've copied your text and inserted what I believe actually happens in bold.
When any push comes from any other job it will start a poll on all jobs that are set to poll. This in turn will cause the branch to see if there are any changes but will not start the build because the commit was from a user whose commits are ignored.
I am assuming you don't mind if the polling happens, but rather that you do not want the build to happen due to a push from that admin work/upper level script commit.
I don't understand your second use case description. If someone pushes and you don't want their build to start that time, but you do want it to start other times, then I don't see a way to use polling to monitor that repository. Polling assumes that a change on a monitored branch is expected to perform the build. Excluded users, excluded regions, and included regions have been used in the past to prevent builds, but the case you're describing with your second use case doesn't match with any of those exclusion techniques as far as I can tell.