I'm having an issue setting up Github and Jenkins CI.
When a forked PR commits changes, github doesn't notify jenkins, even if I've accepted the PR from a forked repo. Only when I merge a pr from a forked repo into master will github trigger Jenkins.
So the credentials and ability is there, but I can't find the option in github to force ALL commits to the original repo (including forked pr's) trigger the CI, anybody any suggestions?
The solution was to use the Github Pull Request Builder Plugin
There are instructions in the link above that worked for me. As well as the default instructions I had to also do this:
"This build is parameterized" and add string parameter named "sha1". When starting build give the "sha1" parameter commit id you want to build or refname (eg: "origin/pr/9/head").
and I didn't use github hooks
A post-receive hook in GitHub would post to any listening service any received commit.
It isn't limited to a particular branch.
However, Jenkins can be set to monitor a specific branch.
Unless, as mentioned in "How can I make Jenkins CI with git trigger on pushes to master?", you configure your Jenkins CI to Poll from GitHub (in which case, it will listen to said Github hook, instead of doing a git pull on a specific branch.
The GitHub pull request builder plugin mentioned by the OP Coombesy 's answer is one other way to make Jenkins poll GitHub.
Related
In a recent build of Jenkins (i.e., 2021-10-01 timeframe), how can I react to a GitHub pull request (PR) Close (or Merge) using declarative Jenkinsfiles and ONLY these "basic" Jenkins plugins?
GitHub plugin
GitHub branch source plugin
It seems that I should avoid GitHub Pull Request Builder since it can't react to PR close or merge.
Currently, everything works fine using a "GitHub organization" type project, when opening the PR and creating new commits on it (i.e., I see "continuous-integration/jenkins/pr-merge"), but when I click Close pull Request in GitHub, the Jenkins Build History doesn't react. I'm not sure why since, the "GitHub branch source plugin" states:
While the build triggers are often enough, you can set up webhooks to
automatically trigger builds when changes are pushed to your GitHub
repositories.
We seem to have an issue merging pull requests which are from forks like here and here. Creating pull request from branches is totally fine and is being triggered by travis ci. Is there some settings which needs to be set for the travis CI? See the travis file here. Thanks.
Answer from travis team:
The checks on the links are branch builds. For them to work, the PR author needs to set up Travis integration for their repo, too, with travis-ci.com, and run a build for the tip of the PR branch. It is this build that the PR UI is “waiting for the status to be reported” of.
The check that would run in your repo is the PR build. It runs on a “merge preview” commit that Github autogenerates for PRs.
The types of the checks to run you configure in branch protection settings at Github.
I am creating jobs using Jenkins Organization Folders.
I want to continuously build against pull request.
However, when I create a pull request, it will be built automatically only the first time.
Even if I add commit to pull request, Jenkins does not build automatically.
I expect that build will work again when the commit is added to the branch that created the pull request.
I am using the following version of Jenkins / plugin.
Jenkins: 2.89.1
GitHub Branch Source Plugin: 2.3.1
GitHub Branch Source Plugin has the following settings.
Discover branches: Exclude branches that are also filed as PRs
Discover pull requests from origin: Merging the pull request with the current target branch revision
Discover pull requests from forks: Merging the pull request with the current target branch revision
Also, although I am using Github Enterprise, I think that the configuration of webhook is okay as the build runs instantly when creating the pull request for the first time.
There is two way to resolve this issue
1)
You have to configure your github repository so it inform jenkins of a new version: yourRepo/settings/hook&service/service ( the best practice)
or
2) you can configure your jenkins jobs so it check for diff time-to-time if the repo have been update :
yourJob/configure/Scan Repository Triggers/Periodically -> 10 min
In my project, we configure both, with a Periodically check of once a day
If you were talking about GitHub Organization folder, then
there is a section where you can configure automatic branch triggering.
Based on this tutorial I was able to successfully connect Github for Desktop with my remote Bitbucket repo.
Looking at the example tutorial repo I see there is an Pull Request option built in the application - great:
However the option is missing when I chose my remote Bitbucket repo:
I couldn't find any option that is reponsible for this.
Anyone knows what affects this behavior?
"Pull Request" is very much a GitHub feature, associated to GitHub repos.
So For BitBucket, the simplest approach is to push your feature branch to the remote repo (which is a BitBucket one, not a GitHub one), and make your PR from there (from the remote BitBucket web GUI, even within the same repo)
Once the PR is initiated, each push done from the GitHub Desktop will complete said PR.
In Bitbucket go to Settings -> Branch Permissions, and add a new branch permission with your name.
EDIT
https://stackoverflow.com/a/37343356/1544886
Say I have a repo and someone forks it. Then they do work and submit a pull request. But the code contains a large number of lines and/or it creates a GUI. I'd like to fetch it so I can actually see it run from Eclipse before merging it into my master. The options I've come up with are:
Create a second repo in EGit and clone directly from their fork.
Create a new branch just for them. Then leave a comment for the request asking them to re-submit the pull request using the new branch and that I'll be closing the current request (without merging)
Always keep around a branch for them to use in their pull requests.
Besides setting up an organization on Github what else could I do?
Then leave a comment for the request asking them to re-submit the pull request using the new branch and that I'll be closing the current request
They don't have to re-submit, it you test and merge first locally, as described in the "Merging a pull request" GitHub page.
git checkout master
git pull https://github.com/otheruser/repo.git branchname
If the local merge works, then you can go ahead and merge the pull request through the GitHub web interface.
GitHub has documented how to checkout a pull request.
As I have illustrated before in "What support for git namespaces exists in git hosting services", you can use refs/pull/<PRNumber>/head as remote pull reference, in command line or in Egit when, for instance, creating a new branch.
If the PR number is 123, you can simply use the EGit Pull action, and use pulls/123/head as reference.