0

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 the Request.state and an embedded Build and its Build.id along with the Build.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 the Build (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?

janpio
  • 10,645
  • 16
  • 64
  • 107
  • 1
    have you checked this: https://docs.travis-ci.com/user/notifications ? I don't know how your application is supposed to work but my idea is the following: use a basic http server with a static IP. If your application is supposed to be distributed then this will be a bit more complicated but not impossible. – Maël Pedretti Dec 10 '18 at 07:29
  • 1
    Thanks for the pointer, I indeed planned to run the app on many different machines, so webhooks weren't really considered. But I looked at it again now: The `id` of the webhook seems to be the `Build.id`, so this could definitely replace the polling part. On the other hand I would need a stateful server component of course that my app could poll or listen to. Maybe, if I don't find anything better. – janpio Dec 10 '18 at 11:30

1 Answers1

1

I will use this answer to document my own research that might help resolve this:

  1. Travis CI API supports eager loading via ?include. Using this, I can already get the Job.id in the Request response via the extended Build objects: ?include=request.builds - I don't have to do another request to build endpoint for the Job.id. But as I need to poll for status changes, this doesn't really help much.

  2. As @Maël Pedretti suggested in the comments, Travis supports webhook notifications. The submitted object contains an id which is the Build.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 :/

janpio
  • 10,645
  • 16
  • 64
  • 107