ashwanthkumar
Using Merge commit to schedule builds is not reliable
Not a very common scenario but still possible. Consider a repository "A" which has a PR#1. Lets say we have scheduled the PR but the build hasn't yet started. In the meantime, if the author of PR pushes another commit to the repository, Github changes the merge commit. Now when Go starts building the commit, the checkout command fails with
01:41:45.042 Interaction with plugin with id 'github.pr' implementing 'scm' extension failed while requesting for 'checkout'.
Reason: [Unsuccessful response from plugin. Plugin returned with code '500' and the following response: '"Cannot read c252d4ae46b290fdb2017b7f9d4b0d717f1da97b"']
01:41:45.281 [go] Job completed proj-PullRequests/1/defaultStage/1/defaultJob on 5a0adb8d6988 [/var/lib/go-agent]
With the https://github.com/ashwanthkumar/gocd-build-github-pull-requests/pull/14 the plugin now polls & checksout to latest revision of a PR. This might not be a problem anymore.
Should we use +refs/pull/*/head:refs/remotes/origin/pull-request/* instead of +refs/pull/*/merge:refs/gh-merge/remotes/origin/* then? we can use refs/remotes/origin/pull-request/ to filter pull requests in that case.
The reason for using /merge instead of /head is, it checks for mainstream merge capability. If we don't use /merge then we should be merging it with the TARGET_BRANCH for the build. Ref - https://groups.google.com/d/msg/go-cd-dev/Rt_Y5G2VkOc/xahPLku-v3cJ
That would mean every commit to master would cause new merge commits on github & hence new builds for each PR? if that is the case it could be very time consuming. for gocd on http://build.go.cd (user: view & password: password) the build-linux pipeline takes about an hour to build & hence running build for every PR for each master change is infeasible :(
If I understand it right, the way Travis does is - For every change in pull requests it tries to merge it with latest target branch. Not the other way round. Unless we are expecting a frequent short pushes to the pull requests, this shouldn't be a problem.
Ref last paragraph in - http://docs.travis-ci.com/user/pull-requests/#My-Pull-Request-isn't-being-built
Sent from Mobile, excuse any typos
In which case - we should check a combination of both target branch sha and pr head sha for the change.
Sent from Mobile, excuse any typos
@ashwanthkumar - we could potentially use merge commits as opposed to top commit of PR for builds. But there is some flakiness inherent to the approach (as you mentioned above). Will see how I can solve this.
@srinivasupadhya is this issue solved correctly? I am still struggling with the same problem
+1
Hello, what's the latest on this? I would also be interested in the plugin allowing to build the merged result with the target branch (i.e. master). That way it can provide feedback that the PR will work before tampering with the target branch.
This is also what the Jenkins Plugin does besides Travis.
Are there any plans for implementing it? Thanks :)
@ashwanthkumar, @srinivasupadhya and others, is there an update on this? I am facing almost the same issue. I look around and saw that this is an old problem. This issue is not the only one exposing this problem, as we can see here for example.
In my case, I see the same error dialog of @yqian1991, but with "Reason" a little bit different, more like @prisamuel on referenced issue above.
The displayed message for me is:
[...] Reason: [The plugin sent a response that could not be uderstood by Go. Plugin returned with code '500' and the following response: '"Exception Occurred: [git, clone, --branch\u003dmaster, https://user:[email protected]/name-of-org/name-of-repo.git. C:\Program Files (x86)\Go Server\pipelines\flyweight\a-big-hash-code] - null"']
How can we go around this? With this, even with the check connection reporting success, Go is not able to start pipelines when pull requests or commits are made.
The git material works without any problem by identifying commits in specified branch, but my proccess is (heavily) dependent on pull requests identification to start pipelines and deliver to production. Without this feature it just don't make sense use Go as our CD facilitator tool. But GoCD is a really exciting tool and I really want to make it work, so if somebody is able to help, please, it would be awesome and I will be grateful forever.
Thanks in advance.
p.s.: I am horrible in english, if my phrases don't make sense, please correct me and let me know that I screw up big time.
@danielterabyte The error is not exactly related to this issue. Can you please create a new issue and we can continue the conversation there? Also specifying the plugin version and the GoCD version you're using would also help.