Jenkins trigger always includes branch name

[monitorjbl]

When the hook is triggered from anywhere except the config popup, it always includes the branch name in the request. I assume this was intentional, but it actually broke something for my team pretty bad. We started out with v2.4 and the only way we could get Jenkins to pay attention to pull request commits was by setting these values for git:

• Refspec: +refs/pull-requests/*/from:refs/remotes/origin/pr/*
• Branch Specifier: origin/pr/*

Everything was rainbows and unicorns until we upgraded to v2.6. Suddenly, the only way to get any PR commit was to fire the trigger from the config popup. After an hour or two of beating my head against my keyboard, I figured out why. In 2.4, the trigger URL never included anything but the git repo. In 2.6, now the branch name shows up whenever a commit is added to a PR or a PR is opened. Unfortunately, the branch name is always the branch of the source repo (i.e., 'master'). The only exception to this is when the trigger is fired from the config popup, which in retrospect makes sense.

Jenkins won't trigger polling for any job that's not configured to read from that branch, so none of our PR builds work with v2.6. We had to downgrade, which is generally a bad thing. Could you add a checkbox similar to "Omit SHA1 Hash Code" that allows us to exclude branch names from the trigger URL?

[mikesir87]

This is certainly something I can add. I may be able to get to it in the next week. Sorry it's been slow responses back to your request.

(And yes... I'd like everything to get back to rainbows and unicorns! :) )

[brentm5]

Has there been any more progress on this? It seems the addition of the branch causes some problems with parameterizing the branch name with jenkins parameters. We have found builds to not start if the branch name in the text field does not match the branch passed from stash. Jenkins for example does not parse parameter values for this check so if you have a parameter named BRANCH_NAME and you set your git branch to be origin/$BRANCH_NAME the build will not be kicked off because its comparing the branch to just $BRANCH_NAME and saying it does not exist.

[karlins]

Thank you for adding a checkbox "Omit SHA1 Hash Code"! It will be very much appreciated an additional check box for a branch name "Omit Branch Name". This will: 1. allow to work with pull requests: otherwise a source branch is always sending to a Jenkins job that makes impossible to parameterize it for pull requests; 2. Use SHA disregarding of a branch name 3. Support old versions of Git Plugins

[brentm5]

@mikesir87 Lets get this back to rainbows and unicorns!

[ashnazg]

In my troubleshooting last week on why my PRs were not triggering builds, I found two things:

• the Trigger Build button on a PR was using 'branch' in its URL, but 'branches' is the correct attribute (#122)
• the handeEvent() method for PR scope changes is completely empty (#125)

When I mimicked a correct Trigger Build URL, even when the branch name given was the source branch of the PR, polling on the PR build jobs would still be triggered, based on the repo URL being matched by the url attribute in the notification. Even in this instance, the inclusion of the SHA1 value did not hurt its ability to match up to the PR builds.

[martinda]

@monitorjbl why do you use pr/* in Refspec: +refs/pull-requests/*/from:refs/remotes/origin/pr/*? I see no such branch when I type git ls-remote upstream. The branches I see are called refs/pull/requests/*/from. Thanks for helping me learn.

[brentm5]

@martinda is the repo that you are looking at a stash repo? We currently have the same sort of setup and if I run that command I see the following <hash> refs/pull-requests/<pr-number>/from listed. What version of stash are you running?

[martinda]

I use Stash 3.11.1 and git ls-remote reveals:

<hash> refs/pull-requests/<pr-number>/from
<hash> refs/pull-requests/<pr-number>/merge

I just don't see the shorter abbreviation pr you mentioned in your other refspec.

[brentm5]

@martinda thats the map for the refspec The syntax from above is basicly mapping pr's so that locally all you have to do is do git checkout origin/pr/<number> instead of git checkout origin/pull-request/<number>/from

[martinda]

@bigbam505 my misunderstanding came from the Atlassian documentation on refspecs. They say that refspecs are of the form +<src>:<dst> where <src> is the source branch in the local repo, and <dst> is the destination branch in the remote repo. Unless there is another way to interpret the official documentation on refspecs, I'll open an issue with Atlassian. Let me know!

[mattadamson]

All,

Reading through does this mean you have a solution to use the plug in when you create PR's from forked repositories?

I thought this wasn't possible because the PR created has a completely different base URL to the one you create in Jenkins. When the plug in looks in jenkins for the job with a matching URL it will never find it as the central URL is defined

Appreciate your thoughts

Thanks