It’ll probably be easier to make the test repo a submodule of the dev repo, or check it out manually in the build logic in the dev repo.
- (The practical difference is: for a submodule, the SHA of the test repo commit to check out is held statically in Git metadata in the dev repo, while if you check it out manually, you can check out whichever commit you want. On the other hand, Travis checks out submodules automatically by default and if you don’t hold the test commit info in Git metadata, you’ll still need to hold the info necessary to make a decision somewhere).
- Then the dev build logic will call the necessary script to run the tests from the resulting checkout.
This way, you’ll see the test result right in the build for the dev commit. If you trigger a build in the test repo instead, that build will have the test result and you won’t readily see in the dev project if a particular commit is good or not.
Now, for your specific question:
For how to trigger a Travis build via API, see Triggering builds with API V3 - Travis CI .
You’ll need to
- give the dev build a Travis token with access to the test project (as a secret variable) to authenticate the request;
- pass the triggered build some info for it to be able to check out the necessary dev commit – probably as envvars in the custom config in the request:
- In the test repo build, use this data to check out the necessary commit from the dev repo
This way, the dev build will always succeed (as long as it could trigger the test build) and you won’t see the test result in the dev repo. To pass the result to the dev build, you’ll need to somehow stall in the dev build and wait for the test build result (via Travis API). You can easily run into the job time limit, and it will be wasting your credits (if you’re on a credits-based plan) or a concurrency unit (if on a concurrency-based plan) while waiting.
- This is why I see this way as an unnecessary complication and do not recommend it.