fetch method returns a promise instead of an actual object. We used find
before, because this was the way we did things before upgrade to Ember
Model. Returning a promise from a model hook pauses router rendering for
the time a resource is loading, which makes it much easier to deal with
asynchronous requests. Thanks to that we can remove parts of the code,
which dealt with it manually.
After update specs fail when there is an unexpected ajax query, because
the response is not an ajax response.
A long term solution is to remove mockjax from specs, because it makes
them brittle and they usually fail after small changes. A better
approach would be to use fixtures, which are available for ember model
When a lot of pusher events come with build updates, lastBuildDidChange
can run quite frequently. We can avoid that by using scheduleOnce, which
will ensure that only the last invocation of lastBuildDidChange will be
run for a given runloop run.
Don't successfully `githubify` strings prepended with an `@` symbol if
what's matched actually resembles an email address. @mentions should
only be githubified if there is a word boundary before it.
This fixestravis-ci/travis-ci#1591
Signed-off-by: David Celis <me@davidcel.is>
lastBuildHash uses information for last build, which is available on the
repo object, so it will not trigger an ajax request if we haven't
fetched a build yet.
When first sync template is displayed, user usually doesn't have any
repos, which also triggers rendering of getting started template. The
fix for this is to handle the action to render getting started page on
first sync and do nothing in such case.
I also added a test to ensure that it works correctly.
When user activates a repository in the profile page, we now will
display this repository on the 'My Repositories' list. When user chooses
this repository, she will see an explenation why there is no builds and
what could be done to fix this.
Conflicts:
assets/scripts/app/controllers.coffee
assets/scripts/app/models/repo.coffee
assets/scripts/app/templates/repos/list.hbs
Ember Model does not do it automatically. I had a patch, which was
changing that, but after giving it more thought, I think it's not a good
idea - this should be up to adapter if the records are going into
record arrays.
When the job is restart, we will not get any updates unless we're
subscribed to job updates - that's why we need to subscribe even if the
job is already finished.
The other option to fix this would be to subscribe and unsubscribe also
based on the status, but since subscribing to finished jobs does not
cost us anything, I prefer the simpler solution.
log property in Travis.Job does not change - we create Log instance
when it's accessed and don't refresh it on any occasion, that's why the
observer on log is not needed.
I changed it to be a Number along with Job's number, but it's wrong -
Build's number should be treated as an integer (to not screw up
ordering) and Job's number can be treated as a string (because it has a
format "\d.\d")
We observe last build on the repo in order to show the freshest build on
repo page. I moved it to router in order to keep such observers in the
same place, but this was not a wise move. To make it work properly
observer needs to be removed when moving to some other part (like
build's page). The problem is that deactivate function is not called
when we move to the other route in the same nesting. We have our own
'activate' function on repoController, which is better suited for
handling this task.
This change pushes the cog menu to the top, where it belongs, as it
now only includes repository-relevant actions. The icons now reflect
things relating to the build/job itself, and have replace the cog
meny.
The hack which is needed for wrong outlet behaviour renders a template
when outlet is not rendered automatically, but it was done immediately.
Because of that when changing routes from index to job route, sometimes
the hack was kicking in and rendering build instead of job template.
This commit fixes it to check if rendering is needed in "afterRender"
phase on runloop.
When adding records just after loading them, the elements in the UI
might have to be updated, which may trigger `get` on associations right
away. As an effect, even if we load a few records on an event (like
repository on build:started event), ember model may end up fetching the
record.
This commit fixes such occurrences by adding record to record arrays in
a run loop, so newly created records will be added at once, after the
event was served.
