Sample of using the `time` element instead of `abbr` for displaying timestamps.
The `time` element can also represent durations. So the sample used here is suboptimal. Rather than the duration time lising the `lastBuildStartedAt` time in the `datetime` attribute, it ought to be a [valid `duration` value](https://www.w3.org/html/wg/drafts/html/master/infrastructure.html#valid-duration-string). However, I didn't see any existing helpers for formatting according to a machine-readable duration value.
When a job is not started, we will show a message that the log can't be
shown. If a pusher message with a state change comes after the first log
pusher message, travis-web-log will error out, because in such a
situation a DOM element wouldn't be available. To make it always work,
this commit changes the behaviour to just hide #log element with CSS
instead of using {{#if}}.
After recent refactorings status images popup started to fetch branches
info whenever a repo page was opened, resulting in additional HTTP
requests. Furthermore, because of a way we load branches, it could
result in builds view displaying very old builds, because in API V2 we
essentially download last build for each branch for branches request.
This commit fixes the situation in 2 ways:
1. We wait with downloading branhes till the popup is open
2. We use a V3 requests to download branches and we don't put that data
into the store
While a job is running, on the job status view, the duration is labeled: "Running for x sec". When the job finishes, 'Running' is swapped for 'Total time'. But "Total time for x sec" doesn't make any sense. the " for" should be part of the conditional with "Running"
This commit fixes handling of branches when using both V3 and V2. The
changes include:
* proper definition of relationships that reflect V3 structure, so for
example build belongs to a branch
* setting up inverse records for some of the relationships. without
doing that Ember Data can handle relationships in a surprising way,
for example if the same record is referenced in 2 places in a
belongsTo relationship, Ember Data will remove one of the references
without proper inverse definitions
* we need to add id when extracting branch as a relationship. Ember
Data expects all of the relationships to have an id
* lastly, we need to mimic the structure of the V3 API in V2 payloads,
so for a build payload I'm now creating a branch record
