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.
Related
How to trigger a Travis CI build after a PR has been merged in github. Basically I have to run some testcases through Travis once the PR is merged in github. I browsed through docs of Travis CI, but was not able to find solution related to running Travis CI once a merge occurs.
I haven't used Travis-CI but I can see that some GitHub commits have a green mark which shows that Travis build has succeeded and some have a red mark which shows that Travis builds failed. But I am wondering why do a few commits don't have any status?
I am looking at the commits of apache commons-math.
Presumably there were multiple commits locally, which was only pushed after commit 583d9ec. Given that the status of an old commit is irrelevant, Travis CI ignores those and only builds the most recent (source). If any issues did arise, a build could have still been manually triggered, revealing which commit broke something.
I have a GitHub repository established with a Multibranch Pipeline job in Jenkins, and until now have been content to require the continuous-integration/jenkins/branch status check, as Jenkins posts when building a local branch from the repo. However, I've now got a pull request from an external fork, and Jenkins has posted a continuous-integration/jenkins/pr-merge status check for that. And because the continuous-integration/jenkins/branch status check is required, the PR is blocked from being merged.
What's the expected approach here, for a project that will have a combination of local branches (from its primary maintainers) and forks (from occasional outside contributors)? Must I forgo having either of the status checks be required on the GitHub side? Or is there some other way to get Jenkins to post a stable status check context regardless of the PR's source?
I had the same issue, with thanks to a helpful colleague I found that, by default, the branch source plugin builds branches that aren't necessarily associated with any pull request.
(Relates to the tickbox "Build origin branches" in the link:
https://go.cloudbees.com/docs/cloudbees-documentation/cje-user-guide/index.html#_controlling_what_is_built)
(WebArchive version: https://web.archive.org/web/20180722083154/https://go.cloudbees.com/docs/cloudbees-documentation/cje-user-guide/index.html#github-branch-source)
This is what creates the status check of "continuous-integration/jenkins/branch".
I unticked that option and ticked the "Build origin PRs (merged with base branch" option, and both status checks now have the same context "continuous-integration/jenkins/pr-merge" and PRs both from forks and branches now trigger the same status check.
In my setup, the tickboxes are in the organisation configuration (since I am also using the GitHub organisation plugin), under Projects > GitHub organisation > Advanced, hopefully on yours, the same options show in your multibranch pipeline config.
Hope this helps
To put it in "BDD" terms:
Background:
Given I'm contributing to a GH repo
When I create a pull request
Then Travis should build the latest commit
When I push to an existing pull request
Then Travis should build the latest commit
When I merge a pull request to master
Then Travis should build master
I was confused by Travis-CI's "build pushes" and "build PRs" settings, as:
Enabling both causes each Pull Request to be build twice by Travis
once for the commit on that branch
and once again for the merge commit of that branch into its destination
Enabling just "build PRs" causes PRs to be built, but doesn't result in post-merge builds (i.e. on master).
Enabling "pushes" brute-force satisfies the above criteria by building all pushes to the repo. You can try to finagle things by white- & black-listing branches, but that will probably bite you unless you're rigorously disciplined with branch names.
This is explained more in Travis-CI docs and GH issue #3241.
Anyone know a configuration that satisfies the above criteria?
I eventually found another GH issue (#2111) which gave me the idea to try enabling both PRs & pushes, but with a whitelist to restrict pushes to a specific branch. This seems to satisfy the criteria for my workflow. Here's what I did:
Enable both PRs & branch pushes in the Travis settings for the repo:
Change .travis.yml to white-list master branch (i.e. only build pushes to master):
branches:
only:
- master
Test it by creating a PR with the .travis.yml change, and another PR with some empty commits to verify it works for forks too.
Verify successful merge commit build from master.
Just found in travis docs
Add to .travis.yml
if: type = push
alternatively:
if: type = pull_request
Assuming you want to build all PRs, something like the following will do the trick. Enable both branch and PR builds on the settings page, and put this line as the first line in your travis.yml:
if: (type = push AND branch IN (master, dev)) OR (type = pull_request AND NOT branch =~ /no-ci/)
This will attempt a push build on all pushes and a PR build on all pushes to an open PR, but will filter out any that don't meet the condition. You might need to modify this a bit - the clause about not building branches with no-ci somewhere in their name is obviously optional, and you may not have two branches that you always want to run builds on.
You can read more on conditions and conditional builds on Travis's site.
The whitelist approach described in the accepted answer has some significant limitations. In particular, it doesn't support non-redundantly building arbitrary branches without opening a PR.
I opened an issue asking for a better solution.
You can use next workflow if you want to test not only master branch but some others branches too:
Keep both "Build pushes" and "Build pull requests" ON
Add branches:except directive to your .travis.yml:
branches:
except:
- /^pr\..*/
In this configuration:
any commit to branch feature-A will trigger the build
any commit to branch pr.feature-A will not trigger the build
if branch pr.feature-A is used in opened pull request then build will be triggered
Workflow example
temporary WIP branch shared between several developers: wip.feature-A, any commit to this branch will trigger the build
when branch is ready to be merged to master you can rename it from wip.feature-A to pr.feature-A and open pull request
if while reviewing pull request you want to apply new fixes, just push to pr.feature-A
On all the steps above only one build will be triggered.
For one of the repositories, I was working with, here is what I wanted:
There is an origin repo which is the main repo which does all the releases.
I wanted that all the pull requests coming to master branch of origin should be built with Travis only once irrespective of the fact that it comes from a forked repo or any other branch of the origin itself.
For this case, this works like a charm
if: (type == push) OR (type == pull_request AND fork == true)
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.