Sergey,
I am the developer who wrote the majority of the server side of Stash's pull request implementation. I'll try to answer this question.
Foremost: I'm going to assume when you say "we are using Jenkins WebHook plugin to trigger job by commit to Stash" you mean when there is a push to Stash, since Stash doesn't support a commit hook (and a manually installed one would never be triggered).
And in point 8 comes the trouble, cause stash updates the reference - "refs/pull-requests/*/from" only if it was Approved, the same with "refs/pull-requests/*/merge" when it's merged....And by commit, "Jenkins WebHook Plugin" is triggered but poll scm at jenkins side is doing nothing cause nothing updated in the remote refs...
This is incorrect. Whether the pull request is approved has no bearing on when refs/pull-requests/*/from is updated, and while actually merging a pull request will ensure refs/pull-requests/*/merge is up-to-date, it is certainly not the only way to do so.
The hashes on a pull request change continuously. The majority of the pull requests in a given repository target a very small number of branches (usually master, for example). Every change to master updates every pull request which targets it. If the system aggressively merged pull requests on every change to their hashes, it simply would not scale. Even throwing a massive box with SSD storage at it would not be enough to keep up with even a moderately busy repository.
To manage that, Stash performs the merge lazily. All you need to do to get the refs/pull-requests/*/* refs to update is view the pull request. Viewing the pull request will automatically trigger those refs on disk to be updated to match their state in the database (which is updated automatically after every push or pull request merge). If the pull request has comments on it, that will also trigger the refs to be updated automatically by a background thread in Stash.
Neither of those will happen in time for your hook, however. Stash doesn't update anything (the database or the refs on disk) synchronouusly with pushes. The amount of processing that will be involved is not sufficiently stable to allow it to be done that way. It may be very fast, or it may take a noticeable amount of time depending on the number of pull requests targeting a given branch.
And it makes a real pain in the process and make not much sense to use "Pull Requests" cause developer can't check his commit (if it's build successfully) after he updated pull request with disscussed changes, so to show reviewers that it passes, but he needs to wait approve and than again initiate unaprove
Actually, all the developer would need to do is view the pull request and the refs would be updated. Approving or unapproving the pull request doesn't do anything in terms of updating them.
Before I continue, there are two things I want to note:
- The way pull request refs work changes radically in Stash 2.9. Prior to 2.9, pull request refs accumulate endlessly. Even when a pull request is declined or merged the system does not remove its entries in refs/pull-requests. As of Stash 2.9, once a pull request is declined or merged its refs are removed and can no longer be fetched. This helps keep the repositories working more quickly because having tens of thousands of refs imposes very noticeable slowdown on many operations, as well as preventing the ref advertisement from becoming very large.
- Doing anything which makes Stash update the pull request refs on disk more frequently may substantially increase the load on your server and cause performance problems. The merges are done lazily because they are very expensive.
With that said. The hook that you are using could be changed to add something like this:
@EventListener
public void onPullRequestRescoped(PullRequestRescopedEvent event) {
PullRequest pullRequest = event.getPullRequest();
//Only trigger this if the pull request was rescoped on the from side, meaning new changes
//were pushed. Doing this after every change on the to side will cause severe performance
//degredation for your Stash server because it happens too often
if (!(event.getPreviousFromHash().equals(pullRequest.getFromRef().getLatestChangeset() ||
//Using getToRef() here is required; pull requests are "scoped" to their target repository
pullRequestService.canMerge(pullRequest.getToRef().getRepository().getId(), pullRequest.getId()).isConflicted())) {
//Notify Jenkins; the pull request refs have been updated
}
}
Calling PullRequestService.canMerge will force the refs to be updated if they don't match the database. PullRequestRescopedEvent is raised whenever the database hashes are updated. As noted in the comments in the code above, you will only want to do this when the from ref on the pull request is updated. If you call it on every rescope event you'll bury your server in merges (and your Jenkins server too, for that matter).
If PullRequestService.canMerge(...).isConflicted() returns true, it means the pull request has conflicts which will prevent it from being merged. If you're building the refs/pull-requests/*/merge commit, it won't build cleanly (and, from Stash 2.9+, that ref does not exist at all if the pull request has conflicts). Hence you'll only want to trigger Jenkins to build the pull request if it can be merged. If you're building refs/pull-requests/*/from, you may choose to notify Jenkins even if isConflicted() returns true; that ref will always exist as long as the pull request is open, even if it has conflicts (even on 2.9+)
Hope this helps,
Bryan Turner
Atlassian Stash
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.