In one of my applications, I want to trigger a Travis CI build, "watch" the build as it is scheduled, run and finishes, then retrieve the final build state and the build log to output it in my app.
I started by triggering a build with the API, which gives me a Request and its request.id. This works perfectly.
- Then I can retrieve this Request, which includes theRequest.stateand an embeddedBuildand itsBuild.idalong with theBuild.state, using the/repo/.../request/#idendpoint.
- I could then start polling /build/#idendpoint to monitor the state every second.
- As soon as the build is finished, I can use the Jobthat is part of theBuild(when requested from/build/#id) to download the log from/job/#id/logand display it in my application.
This all sounds pretty inefficient.
Is there a better way to achieve this?
Is there a "quicker way" (= less requests) from creating the request to log?
Can I avoid the manual polling somehow?
 
                        
I will use this answer to document my own research that might help resolve this:
Travis CI API supports eager loading via
?include. Using this, I can already get theJob.idin theRequestresponse via the extendedBuildobjects:?include=request.builds- I don't have to do another request tobuildendpoint for theJob.id. But as I need to poll for status changes, this doesn't really help much.As @Maël Pedretti suggested in the comments, Travis supports webhook notifications. The submitted object contains an
idwhich is theBuild.id, so this could replace the polling part I described above. As my app doesn't just run on one server that can be configured as the webhook url though, I need a stateful server component that my app could poll or listen to. So just a horse trade :/