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
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.