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.state
and an embeddedBuild
and itsBuild.id
along with theBuild.state
, using the/repo/.../request/#id
endpoint. - I could then start polling
/build/#id
endpoint to monitor the state every second. - As soon as the build is finished, I can use the
Job
that is part of theBuild
(when requested from/build/#id
) to download the log from/job/#id/log
and 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.id
in theRequest
response via the extendedBuild
objects:?include=request.builds
- I don't have to do another request tobuild
endpoint 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
id
which 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 :/