We don't want to subscribe if we're at any other routes, because there is no
data there. The main target is to avoid all of the notifications from a common
channel if we're on the /dashboard route.
Technically jobIdForLog should be sufficient, because it has job id only when
it's a job or a build page, but for some reason it doesn't get refreshed
properly.
For some reason when we run get('build.jobs.firstObject.id') it returns
different result than get('build.jobs').objectAt(0).get('id'). I can't reproduce
it on a clean Ember application, so it's probably a consequence of something
that we do in our views.
Almost all actions on views were not properly handled, because they were still
methods directly on a view object rather than in `actions` property. This commit
fixes it.
This commit starts refactoring of one of the remaining areas where we do weird
tricks to get the desired behaviour. Namely, we were treating "my_repositories"
and "recent" not as individual routes with separate URLs, but only different
states on the repos controller. Such approach leads to various problem with
connecting outlets on rerenders (ie. we don't explicitly connect outlets when
changing from one view to another programatically).
A new cleaner way is to change both tabs into routes.
This part needs further refactoring, but for now I just fixed log view to
teardown and setup things properly in all cases something changes (when element
is inserted or removed, but also when log object is changed).
Layout handling in travis-web was implemented in a dynamic way, so we
could change a main layout from any of the routes. This needed a
`rerender` call which was making things harder and needed some hacks. It
also broke a few transitions when upgrading to 1.8.1.
After examining our usage of layouts I've noticed that we don't need to
change the entire layout dynamically and instead we can set layout on
root routes (like "index", "profile" and other root routes).
