We can't check 'isFinished' when model is asked for
isAttributeLoaded('state'). In such situation, it will go to isFinished
and call @get('state'), which will trigger isAttributeLoaded('state')
again.
This commit breaks login in Safari, without it people will need log out
and log in again if they experienced 401 requests on the profile page,
but we can't break Safari.
It seems that the root cause of the error is the fact that auto sign in
fails in Safari.
This reverts commit d84b3581eb.
We change ansi terminal instructions into HTML tags before splitting the
log into lines, which sometimes may end up with </span> in the beginning
of the line. This is a quick hack to fix that problem, but we need
better solution.
After change log rendering method, to append HTML elements instead of
rerendering the entire thing, the case of gradual rendering of a log
started to behave much better (because we just append new elements), but
the initial render took a bit longer, because of the fact that appending
large separate HTML elements to DOM at once is not a good idea.
In order to make the situation better I added simple optimization.
Elements are added to DocumentFragment node before inserting to DOM and
appended to DOM only after all elements are processed. That way, when
log needs to be rendered all at once, we will not do any DOM operations
until log is ready.
Till now, log viewer was rendered in handlebars, which was the simplest
solution, but it had a major drawback - every append to log caused it to
rerender which was not efficient and memory consuming.
The new approach is to make Travis.Log interpret the log and send lines
with instructions to the view, so for example if view should add a line,
it gets something like:
{ number: 1, content: '$ bundle install' }
Such approach is required to handle cases where data coming from pusher
is not actually a new line. For example output containing dots from
tests needs to be appended:
$ rake
....
Such output could be sent to client in 2 chunks: "$ rake\n.." and "..".
In such situation we would need to send 3 instructions:
{ number: 1, content: '$ rake' }
{ number: 2, content: '..' }
{ number: 2, content: '..', append: true }
The third instruction can come much later, because tests can take a
while to run, so we can't assume that each line will come in one piece.
The other scenario is \r, for example when showing progress:
\rDownloading: 10%
\rDownloading: 50%
\rDownloading: 100%
Such input should be changed into such instructions:
{ number: 1, content: 'Downloading: 10%' }
{ number: 1, content: 'Downloading: 50%', replace: true }
{ number: 1, content: 'Downloading: 100%', replace: true }
Travis.Log also supports folds, for example on bundle install, the code
was rewritten to make folds management simpler.
We sometimes get "done" as a response body from API when authenticating.
We should properly fix it in the API, but for now I will add this quick
fix to not completely break on login when it happens until we have
proper fix.
Default regexp used in ember does not work well for us. With repos
starting with 'stats', ember will match such url for /stats/ page, even
though the rest of the url is different, I added ability to overwrite
default regexp.
Commit fields come in with build:started payload. We should split it
into 2 separate keys in the payload, like:
{
build: { .... },
commit: { .... }
}
but I can't change pusher v1 API at the moment, due to backwards
compatibility with the old client. We will be able to remove this manual
extraction as soon as we switch to pusher v2 API.
I couldn't reproduce it locally, but I got this exception once. This
implementation will need to be rewritten after upgrading to newest
ember, so I'll leave it as it is for now.
When using get with path (eg. get('foo.bar.baz')), get method is called
only on the current object and computed property will be called. Because
there is no easy way to overwrite the computed property, I moved
incomplete record loading to ember-data. It's not DRY and it should be
rewritten, but I don't want to do it at this point as we will need to
completely rewrite it when upgrading ember-data.
It's best to do that, because worker payload is usually outdated. If
there is no info on repo yet, it's worth to add it, but if it already
exists, we will most likely end up with inconsistent situation.
It's best to do that, because worker payload is usually outdated. If
there is no info on repo yet, it's worth to add it, but if it already
exists, we will most likely end up with inconsistent situation.
