fix(travis): Enable legacy log fetching #1075
Conversation
|
The following commits need their title changed:
Please format your commit title into the form:
This allows us to easily generate changelogs & determine semantic version numbers when cutting releases. You can read more about commit conventions here. |
jervi
force-pushed
the
enable_legacy_log_fetching
branch
from
2cf3701
to
3785320
Compare
|
@spinnaker/oss-reviewers PTAL 🙂 |
| @@ -83,17 +82,22 @@ public Map<String, TravisService> travisMasters( | |||
| igorConfigurationProperties.getClient().getTimeout(), | |||
| objectMapper); | |||
|
|
|||
| boolean useLegacyLogFetching = false; | |||
There was a problem hiding this comment.
For the record, it looks like this came from #449.
There was a problem hiding this comment.
Yes, correct. We had high hopes for this feature 😢
| @@ -62,7 +62,12 @@ public boolean isReady() { | |||
| } | |||
| int numberOfParts = logParts.size() - 1; | |||
| V3LogPart lastLogPart = logParts.get(numberOfParts); | |||
| return numberOfParts == lastLogPart.number && lastLogPart.isFinal(); | |||
| String logContent = getContent(); | |||
There was a problem hiding this comment.
This seems like a new change...not reverting part of #449 ... Is this at least sort of, a separate improvement?
There was a problem hiding this comment.
Correct, this is an improvement. Travis will always end a build (failed or not) like this.
igor-monitor-travis/src/main/java/com/netflix/spinnaker/igor/travis/config/TravisConfig.java
Outdated
Show resolved
Hide resolved
We've had lots of trouble with the log_complete feature Travis added a while back on our request. It was supposed to solve our issues with figuring out when logs are actually available (which can be up to several minutes after the build is complete) - but basically it can't be trusted. We've seen cases where it turns to true even before the build was completed (how can the logs be done then? 😆), and also in the opposite case, it can return false for a long time even though the logs are in fact complete. So it's better to just fall back to the old way of checking log completion (with some improvements). We've been running this internally in Schibsted for several months, and have not seen any issues with log fetching during that time - a huge improvement from earlier!
jervi
force-pushed
the
enable_legacy_log_fetching
branch
from
a8ec1d4
to
47b0377
Compare
We've had lots of trouble with the
log_completefeature Travis added a while back on our request. It was supposed to solve our issues with figuring out when logs are actually available (which can be up to several minutes after the build is complete) - but basically it can't be trusted. We've seen cases where it turns totrueeven before the build was completed (how can the logs be done then? 😆), and also in the opposite case, it can returnfalsefor a long time even though the logs are in fact complete. So it's better to just fall back to the old way of checking log completion (with some improvements*). We've been running this internally in Schibsted for several months, and have not seen any issues with log fetching during that time - a huge improvement from earlier!* The log complete check will now check that the log output contains one of two phrases that all Travis builds should always contain - either
Done. Your build exited withortravis_terminate.