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.

markewaite: Resolve as incomplete as there's been no response to your comment in several weeks?

Needs more information before we can decide if any action is needed. Marking as incomplete since it has been two weeks without a response.

I'm not the original reporter however I just noticed the same thing in the combination of TFS2015 and Jenkins. TFS2015 provides a service hook to Jenkins which sends a GET request to the following URL:

http://myjenkinsserver/git/notifyCommit?url=http:%2F%2Ftfs:8080%2Ftfs%2FProjectCollection%2FProject%2F_git%2FRepository&sha1=32b21f5e74c51d2054ffed71ddfc46f79c08a9d0

In our case each repository may have multiple builds looking at the repository but each build is looking at a different branch, e.g. we have a build looking at the master branch (branches to build = /master), one at all the feature branches (branches to build = */feature/*), etc. etc.

The problem is that the given SHA is only on a single branch (in this case feature/testintegrationwithjenkins) so I was expecting it to ONLY trigger the build that is looking at the feature branches, not the other builds. However it's triggering all builds looking at the given repository. According to the documentation that is the correct thing to do however I don't think it is. The job definition states that it will only build code that is on a given branch but this by passes that, thereby potentially building with an incorrect job configuration.

petrikvandervelde Commit notifications can send a parameter branches along, so that would probably solve your problem.

Yeah it probably would. The only unfortunate thing is that I don't control the way the URL is formatted. That's done by TFS Guess I'm going to have to file a bug there as well.

Ok so version of TFS2015.1 does indeed pass the branches parameter, however this only partially resolves the issue. I still think there is an issue with the GIT plugin.

When a tag is pushed to the repository a push notification is send to jenkins as well. Because tags aren't related to a given branch only the SHA is send, thus leading back to the problem I discussed above, being that all builds for that repository are triggered regardless of the fact that the build configuration is relevant for that tag. That then leads to many failing builds.

I think the correct solution(s) would be to either ignore notifications without a branches parameter IF the user has configured the job to look at a specific branch (or set of branches) OR to give the user a configuration option to ignore notifications without the branches parameter.