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.
Related
Any new commits I push to my Github repository automatically triggers the CircleCI workflow which is great.
When I create a new pull request, the statuses of the workflows are reflected in my PR. All of these are fine.
However, I have recently added code coverage in my workflow to automatically post comments to my PR after the checks. If I didn't create the PR immediately after I push my commit and had only created the PR after the workflows have finished running for the commit, the bot is not going to post any coverage comments to my PR because the workflow has already been run for that commit. The workflows don't get re-run again when I create a new PR with that commit.
Is there anyway to force CircleCI to re-run the workflows again when a new PR is created?
GitHub creates a new ref when a pull request is created. The ref points to a merge commit, which is the merged code between the source and target branches of the pull request. The PR validation pipeline builds the commit this ref points to. (from here)
This causes a problem for my pipeline with Chromatic: these commits are problematic for a bunch of reasons. The biggest one is as they don't exist in the git history, we lose track of baseline acceptances you do on them.
Is there a way to configure GitHub and/or Azure DevOps build pipeline to trigger build for PR but for normal linear commit in PR branch, not merge of it with target branch?
Is there a way to configure GitHub and/or Azure DevOps build pipeline to trigger build for PR but for normal linear commit in PR branch, not merge of it with target branch?
I am afraid there is no such way to trigger build for PR but for normal linear commit in PR branch.
Just like what you pointed, PR validation pipeline is used to build the merged code between the source and target branches.
If you do not want to build the code merge of it with target branch, you can just set the build pipeline with CI trigger enable for the source branch instead of the PR build for the PR validation pipeline.
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.
How is it possible that Travis the build failed for the latest push but passed the Pull Request?
On this Gist, you could find the failed and passed output log of the npm run build command that Travis gives. You could also find the configuration of Travis and here below:
install:
- npm install
- npm install -g angular-cli
language: node_js
script:
- gulp html
- gulp scss
- gulp ts
- gulp node
- npm run build
node_js:
- "6.9"
cache:
directories:
- node_modules
- bower_components
Background
This repository is configured in Travis CI to run tests on two environments - named pr and push.
A Pull Request (pr) build will be named continuous-integration/travis-ci/pr and from the docs:
Rather than test the commits that have been pushed to the branch the pull request is from, we test the merge between the origin and the upstream branch. To only build on push events, you can disable Build on Pull Requests from your repository settings.
A push build will be named continuous-integration/travis-ci/push and from the docs
Travis only runs a build on the commits you push AFTER adding the repository to Travis.
Solution
Since the merge of your branch into the base branch passed tests for continuous-integration/travis-ci/push, updating your branch to include the latest commits from the base branch will get your branch passing tests. From the image above, the GitHub UI should allow you to Update branch from the Pull Request page.
Caveat
With branch protections in place, it should be unlikely that your branch fails tests while merging into the base branch succeeds.
Be sure that you confirm that whatever was broken was actually fixed. That is, did someone "fix the build" by disabling that failing test in the base branch? As a cautious person, I would cherry-pick fixes into your branch to verify the problem is resolved.
By a comment of #osowskit, I've found the solution of the problem. He/she said:
PR will merge your changes into the base branch and run CI tests. Push will run CI tests on the current branch. Merging the base branch into your branch will likely resolve your build test on the branch.
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.