Hi there,
Not sure if I miss this in documentation or this feature is missing but I’m wondering if it’s possible to trigger build via API for pull request made from fork?
I came here from https://github.com/travis-ci/travis-ci/issues/9907. In https://github.com/web-platform-tests/wpt/issues/14499, after migrating from travis-ci.org to travis-ci.com, it’s a problem that all existing open PRs require a passing check from the new travis-ci.com integration, but there’s no way to trigger the builds other than modifying the PR.
Thanks for pointing this out. We will take a look at this issue shortly (if not before the holidays, shortly after).
Are there any news?
I would like to build a GitHub app that allows you to re-trigger PR builds!
Hi, is there any new on this ? It would be a huge help to be able to trigger builds for references/PRs using the API.
Is there any update on this?
FWIW, you can retrigger a build for a PR by pushing an empty commit to its branch.
Thanks but it’s the initial triggering of a PR build via API that I’m interested in, rather than re-triggering.
There’s no difference. If Travis integration is set up for a repo, whenever a commit is pushed into it, a build is triggered.
(If that doesn’t describe your scenario, to avoid hijacking the discussion, please create a separate topic and explain what you’re trying to do, linking to relevant materials.)
I think what I’m trying to do is relevant to this thread. The first response by foolip contains a link to a Travis issue which is essentially what I’m trying to achieve and links to this Feature Request. https://github.com/travis-ci/travis-ci/issues/9907
Both of edouardpagnier’s comments in that issue explain what I’m trying to do.
I know that PR can be built automatically when it’s configured in the Travis settings, however I want to trigger them manually throw the API.
Could you describe the use case behind this?
Because as per below, this sounds contrary to Travis CI’s purpose so you’re probably going to be better off using some other method.
The entire purpose of CI is to trigger automatically for every commit rather than manually. PRs are intentionally subject to stricter scrunity and thus given less leeway than pushes because they are untrusted code that is to go though a “proper process” of code review, checks and such before it’s accepted into the “trusted” codebase.
In particular, manual build (re)starts are intentionally prohibited to prevent contributors from smuggling unreliable code in: they can retrigger checks with empty commits but the PR would show exactly what they did.
It won’t be manual, as such, it would be triggered by automation. We’re using our own Travis Enterprise and would like to programmatically generate the content of the .travis.yml in order to enforce that certain steps are run as part of the build across an org/multiple projects, since it’s not possible to have a global/separate reusable .travis.yml (explained well here https://github.com/travis-ci/travis-ci/issues/5385 and similar to this gitlab functionality https://about.gitlab.com/blog/2018/02/22/gitlab-10-5-released/#include-external-files-in-cicd-pipeline-definition)
Anyway, I won’t clog this thread any longer. I just wanted an update since BanzaiMan mentioned above about looking into it. Thanks
This sounds like a job for Github build checks and/or Git commit hooks which would check and/or automatically edit .travis.yml for compliance. Common scripts, if any, could be a submodule, or downloaded at the start, or even be preinstalled at custom build VMs since you are an enterprise user.
You can also take a look at something like Google’s repo and appraise tools that they use for Android codebase. To my knowledge, they enable multi-repository commits/PRs and code review; dunno if they have global checks/hooks.
I came across this feature request while trying to customize my own Travis build. In my case, I have 20 test jobs that correspond to individual sub projects. Each sub project contains integration tests that are expensive to run. When a PR is submitted a Travis build is run that runs all 20 test jobs, even though the changes in any PR usually only apply to a single sub project. I have a check that skips running tests for sub projects that have no changes, by checking if paths have been modified, but this check runs as a script after the VM boots up. Even if one sub project has changed I spawn 20 test jobs, 19 of which basically do nothing, but I still have to wait for the VM of each to spin up, check for changes and shutdown.
The idea that led me here was to disable the automatic “Build PR” feature for the repo, run a script that responds to GitHub webhooks for a PR, and then trigger a Travis build through the API with env vars that will control exactly which test jobs to run.
@native-api Can you elaborate on how this might be accomplished using GitHub build checks and/or Git commit hooks as you suggested in your last comment?
@seglo My previous post was replying to a completely different scenario – they needed to do additional checks that could be made independently from the Travis build.
For your case, runtime checks is the way to go. The most you can do is move the check before any time-consuming logic – e.g. software installation. You can also upvote the Run a chunk of user code before the stock installation logic feature request that would allow you to do this while still taking advantage of stock addons that install stuff.
Be careful though about which tests you exclude. If a change affects one module, you need to run not just unit and integration tests for it but also integration tests for all modules that it interfaces with and full-system tests that use this module’s functionality.
It turns out that Github doesn’t support regular server-side Git hooks – but uses webhooks instead. You can see https://github.com/travis-ci/docs-travis-ci-com/pull/2764 for an example of 3rd-party webhooks with additional checks. This is not for your use case though.