| We're having some issues where some of our developer's pull requests are not reporting that the "Jenkinsfile not found" when we know that their branch does indeed have the Jenkinsfile. We first noticed it with GitHub webhooks that trigger the event when there is a change to the pull request.. that also reports "Jenkinsfile not found". Here is a snippet of the log:
```
[Fri Nov 23 09:13:55 PST 2018] Pull request #35771 updated in repository Safe/fme UPDATED event from xxx.xxx.xxx.xx → xxx.xxx.xxx.xx → xxx.xxx.xxx.xx⇒ http://xxxxx/github-webhook/ with timestamp Fri Nov 23 09:13:48 PST 2018 processed in 2 sec
[Fri Nov 23 09:27:55 PST 2018] Received Pull request #35897 opened in repository Safe/fme CREATED event from xxx.xxx.xx.xxx → xxx.xxx.xxx.xxx → xxx.xxx.xxx.xx ⇒ xxxxxxxxx/github-webhook/ with timestamp Fri Nov 23 09:27:50 PST 2018
09:27:56 Connecting to http://xxxxxx/api/v3 using bbuilder/****** (Bob the Builder's Credentials)
Examining Safe/fme Checking pull-requests... Getting remote pull request #35897... Checking pull request #35897
‘jenkins/Jenkinsfile’ not found
Does not meet criteria Checking pull request #35897
‘jenkins/Jenkinsfile’ not found
Does not meet criteria 2 pull requests were processed Finished examining Safe/fme
``` We then tried to use the "Scan Repository Now" feature to see if it would find it then.. but that also failed. We dug into the plugin source code and found that it was trying to access this API endpoint on GitHub: http://xxxxxxx/api/v3/repos/Safe/fme/contents/jenkins?ref=pull/35897/merge The response from that API call was this: ``` { "message": "No commit found for the ref pull/35897/merge", "documentation_url": "[https://developer.github.com/enterprise/2.14/v3/repos/contents/]" }
``` After some time, the API somehow refreshed and it now properly returns the right contents and the pipeline is now working for that pull request. Aparently this API call to get the '/merge' refs is an undocumented feature and not fully supported by GitHub. http://xxxxxxxx/api/v3/repos/Safe/fme/contents/jenkins?ref=pull/35897/merge Here is their response to that: ----------------------------------
Hi xxxx, The /merge refs are an undocumented feature and we don't recommend relying on them as they're subject to change at anytime. This feature was built to power the Pull Requests feature in the GitHub Web UI, it was not built to be used by 3rd party services or tooling such as an API. As this is undocumented, you should not have any expectations about the behavior, the behavior might change at any time and those refs might completely go away without warning. In our current implementation, the pull/*/merge reference should be eventually updated when either the head or base branch of the pull request being pushed to. This happens in the background that is run asynchronously and GitHub Enterprise does not guarantee that it will be available at any specific time after a pull request's head branch is pushed to. It's also possible for the merge ref to be missing or point to an out-of-date merge; for example, if the latest push to a branch causes a merge conflict. Again, we do not recommend relying on this ref and instead recommend you update your jobs to use the head branch. For example: http://xxxxxx/api/v3/repos/Safe/fme/contents/jenkins?ref=pull/35897/head
This should always be available after a push completes. If you'd like to test the result of a merge with the base branch, your CI server can either perform the merge locally, or you can [configure a required status check with the strict policy](https://help.github.com/enterprise/2.14/user/articles/types-of-required-status-checks/, which will ensure that the head branch is always up-to-date with respect to the base before merging is allowed. Let us know how that works for you and please do not hesitate to reach out with any further questions. Thanks, Brian
---------------------------------- With that, it seems the GitHub Branch Source Plugin is may not be very reliable and could potentially break at anytime. |
