Skip to content
This repository was archived by the owner on Dec 20, 2025. It is now read-only.

igor 3.4.0

Choose a tag to compare

@robzienert robzienert released this 27 Jun 19:11
feat(travis): Support for log_complete from Travis API (#449)

* feat(travis): Support for log_complete from Travis API

Travis added a new property in version 2.2.9 (also available on travis-ci.org) that tells us if the log is complete or not. This allows us to be more efficient in the way we fetch artifacts and properties from Travis. It is not backwards compatible, so we have to keep the old way of doing it around for a while.

Each Travis master will be queried at Igor startup for some simple feature detection to determine wether to use the legacy method or the new method.

A few interfaces has been changed to use GenericBuild instead of `buildNumber`. This allows for some reduction in complexity for a few of the providers that don't use `buildNumber` internally, as we don't have to query the master for `buildId` multiple times.

If log_complete is false, we fall back to use the legacy log fetching. The reason is that the travis log endpoint actually returns the complete logs for a while before the flag turns to `true`. If we only wait for the flag, the delay between a finished build and the Spinnaker pipeline triggering can become very long. On the flip side, we can use the flag to avoid downloading the logs to check for builds where we know the log is completed. This gives us the best of both worlds (ideally Travis should fix this in the API, but I'm not holding my breath).

Also contains some spring cleaning of the TravisClient and the TravisService, it contained a lot of unused methods.

* Don't purge builds from the tracking cache before the log is ready