Trigger build on new push to pull requests #38
Comments
|
I'm confused, because our Jenkins jobs configured to watch pull requests already do pick up new commits to PRs and do builds for them. Now, there is an odd behavior in Stash itself that I've not yet figured out, though I have found a workaround for it... Occasionally, for a new commit added to an existing PR, if you click the link to view the commit, Stash returns a 404. I've even seen this happen repeatedly for several commit links on the same PR. Further, as long as these pages 404, I've seen that Jenkins is NOT getting notified about the commits, and thus no new builds. The workaround here is to view the Diff tab on the PR. It's as though Stash having to handle the Diff view is what actually creates the individual Commit pages, and once these Commit pages are available and not 404ing, then the Jenkins notifications happen and new builds happen. My app versions are: Stash v2.6.2; Jenkins v1.535. |
|
Hmm... nice to know. I haven't done too much with adding to pull requests yet, but plan on doing so this weekend to figure out what I may be able/need to do. Thanks for the info! |
|
So, it looks like I have the code working in its tests, but wanted to check in a real setup. However, I'm having trouble getting Jenkins to see the current pull requests. I tried following the instructions posted in the original issue, but got Was there any other setup you needed to perform to fetch those refs? I found a related Atlassian Answers post (https://answers.atlassian.com/questions/188883/building-pull-requests-from-stash-on-bamboo), but am interested in how you have your systems setup. |
|
Hi Michael, Nice work! Let me know if you have any further problems with the setup! Kind regards, Melvyn de Kort On Tue, Dec 17, 2013 at 4:47 AM, Michael Irwin notifications@github.comwrote:
|
|
Are you intentionally using /merge rather than /merge-clean? As best I can tell, watching /merge will mean triggering builds even though Stash already knows a merge will fail. If you instead only watch /merge-clean, then you'll only trigger a build if a PR can successfully merge to its target. On our build system, I'd originally set up separate builds jobs to watch the various PR-related branches separately:
I eventually realized that a /merge build for a good merge is just a duplicate of /merge-clean. Further, any /merge build without a duplicated /merge-clean build means I ran a build against corrupt code (because it contained conflicts), and thus the build actually meant nothing useful. The PR itself should be indicating the merge failure condition itself, without requiring a failed build alongside it. |
|
Hi Chuck, Yes, this is intentional, since the merge-clean or merge-fail don't always Kind regards, Melvyn de Kort On Tue, Dec 17, 2013 at 6:55 PM, Chuck Burgess notifications@github.comwrote:
|
|
By the way Chuck, you should read the response of Bryan Turner (Atlassian He says here that since Stash 2.9 the /merge commit doesn't exist at all The soon to be updated stash-jenkins-postreceive-webhook plugin will only Kind regards, Melvyn de Kort On Wed, Dec 18, 2013 at 10:10 AM, Melvyn de Kort melvyn@mdekort.nl wrote:
|
|
That's good info. I've always been a bit worried about hitting those internal refs like that, as anything non-API is subject to change like that. I'll have to keep these things in mind when we migrate into the newer Stash versions. |
|
Ok. Just pushed up the new code. Want to take a look and see how it works out for ya? I'll take another stab at getting my own instance working. |
|
I'll take a look at it in the morning, it's 10:22 pm here in the Netherlands ;-) |
|
Sounds good! Have a good night! :)
|
|
Doesn't work yet, the IsMergeableEligibilityFilter still assumes all incoming events are of type PullRequestRescopedEvent. |
|
Wow... totally missed that for some reason. Thanks for letting me know. I'll get it patched up using your code. |
|
Ok. Just pushed up another code set (forgot to tag the issue in it). Should work for ya now. :) |
|
Yep, that did it, successfuly tested open, decline -> reopen and rescope. |
|
Sounds great! I'll go ahead and prepare it for release and get it updated in the Atlassian Marketplace. I'm not sure how quickly it'll propagate through their system, so may take a little while before it shows up. Thanks for all of your help! |
|
No problem, we needed it, so I'm happy to help. |
|
Sure thing. May not be what you have in mind, but for the mean time, you can always trigger by testing the settings from the webhook settings panel. Hitting the test button does send a trigger to Jenkins. But, I'd be happy to hear what you've got in mind. :) |
|
That would indeed temporarily help us. |
|
Hey Mike, I can report working behavior from a pull request we processed through yesterday, via Stash 2.10 :-). However, once the PR was merged, our separate job that watches the DEVELOP branch in order to do post-merge builds was never triggered. We saw this error in the Stash log: 'com.atlassian.stash.event.pull.PullRequestMergedEvent[source=com.atlassian.stash.internal.pull.PullRequestServiceImpl@27fe07f9]' for the invoker 'SingleParameterMethodListenerInvoker{method=public void com.nerdwin15.stash.webhook.RepositoryChangeListener.onRefsChangedEvent(com.atlassian.stash.event.RepositoryRefsChangedEvent), listener=com.nerdwin15.stash.webhook.RepositoryChangeListener@724633e6}'. Is perhaps one of those PR-related filters mentioned earlier unintentionally blocking non-PR event posts now? |
|
@ashnazg - I'm looking into it now, but feel free to follow the new issue for updates, as this one's closed now. |
|
Hi All, sorry if this is not the right place to ask this - but I have the above working correctly building pull requests however I am unable to figure out how it is possible to display the results of the pr build within stash on the PR tab. Is this possible? Many thanks |
|
With this Jenkisn Plugin: 2014-06-23 16:31 GMT+02:00 Tom Barber notifications@github.com:
|
|
Thanks, i've actually configured that plugin already but isnt working as i expect for PRs. I should have posted my question on a forum for that plugin. Many thanks |
|
Hi, I'm currently trying to setup stash (3.4.0) with jenkins with a similar setup. We are currently using gitflow setup and developers have no access to commit to develop or master branches so only pull requests will work. I've defined the ref specs as +refs/pull-requests/:refs/remotes/origin/pull-requests/ |
|
@joaofernandes my refspecs include a wildcard: though I'm not convinced they're entirely necessary. However, I do think the "branches to build" setting does need them: That third level of the branch paths has your PR# in it. I think that's why your jobs are failing to trigger. |
|
Hi Guys, unfortunately this doesn't seem to work for me.
and the corresponding branch:
every time I trigger the build only my "feature"-Branch build is triggerd but not the merge branch one. |
|
Try this: branch: It was some time ago that i was playing around with this and I believe the above worked correctly, though am unable to check at the moment. |
|
Still not working. When I update a pull request nothing gets triggered in jenkins but if I press trigger build inside the pull request page, It starts building the project. |
|
On the build job itself, do you have polling enabled? A "schedule" is not necessary, so that can be left blank, but "polling" does need to be toggled "ON". If you check your Jenkins log (Manage Jenkins -> Systems Logs -> All Jenkins Logs), you should see a record of the Stash notification coming from the pull request update, and any jobs that are configured to poll against the notified refspec/branch will report a record of their poll request back to Stash to find new commits. If your jobs are not configured to poll, you'll only see the Stash notification record. If you don't even see the Stash notification record, then I'm very confused, because that would indicate a Stash-side config problem, one that should also prevent the Trigger Build button on the PR from functioning. |
|
Polling is enabled since first configuration and ignore post commit hook is "off". Sometimes the build really starts once a commit is done to an existing pull request but most of the times it doesn't. It's like if the references aren't updated so when the webhook plugin notifies jenkins and jenkins activates pooling it won't detect what was changed in the pull request. Here is the log after committing to an existing pull request This is after manual triggering build manually: As you can see there is a different behavior going on. |
|
Ok so in GitLab if you would like to trigger auto build using Poll SCM for only merge requests you can use the below syntax under Refspec and Branch Specifier (blank for 'any') respectively .... it will work perfectly
|
(copying comments from blog)
-- Comment from 12/4 11:10
We tried to use your plugin with Stash Pull Requests, but encountered a problem, I know that it is on Stash side, but want to ask if you have some workaround in mind:
What we want to accomplish is:
(we are using Git Plugin in Jenkins and specifying refspec
parameters: "+refs/pull-requests/:refs/remotes/origin/pull-requests/"
and building the "origin/pull-requests/*/from" branch)
Jenkins WebHook plugin is setup to trigger job by commit to Stash Repo
(Here we get trouble, cause your plugin is sending trigger after commit, but poll scm from Jenkins can't find nothing, cause stash updates the reference - "refs/pull-requests/*/from" only if it was Approved in Pull Request)
But to update reference and have additional commits in the same Pull we need to Approve and Unapprove each time after commit, which is makes no sense
Do you have any workaround or any ideas how to adopt this to Pull Requests process?
------ Comment on 12/4 11:57
I got a fast reply from Atlassian Developer according to this.
Michael could be interesting for you as a feature, since he also submitted some code snippet how to solve this - https://answers.atlassian.com/questions/239988/change-pull-request-refs-after-commit-instead-of-after-approval-or-workaround
The text was updated successfully, but these errors were encountered: