We use adapter.findRecord to fetch repo by slug. Using it this way was
broken with one of the ember-data releases. This commit brings back the
old behaviour.
We pass runningJobsCount to repos-list-tabs component, which essentially
is a binding and a binding will call the property that we're passing,
which in turn will fetch running and queued jobs. In order to avoid
this, I added guards in computed properties.
The `activate` hook is not always called when the route is used,
specifically it will not be called when the model changes, but the
change happened within the same route (for example when switching from
/travis-ci/travis-web to /travis-ci/travis-core). `beforeModel` is
guaranteed to be called every time the model is changed, both when the
route is entered for the first time and on any subsequent calls.
Note: There is a [known issue](https://github.com/mixonic/ember-cli-deprecation-workflow/issues/30) with a deprecation warning coming from
...wait for it... ember-cli-deprecation-workflow.
Otherwise, this simply bumps the necessary dependencies (suggested by
the new generators) and makes the project conform to the minimal changes
in import syntax.
An [issue](https://github.com/travis-ci/travis-ci/issues/5181) was reported in
which the repository sidebar links were not functioning properly. I've
tracked it down to the fact that a click handler was registered and
automatically performing a redirect to the repo route.
This breaks CMD+Click behavior (as the click handler was still
called and navigating when the user did not expect it, as well as
navigated to a link that the user did not intend to visit.
This commit simply removes that click handler. I checked the previous
coffee version of the file to gain more context on why it was initially
added, but unfortunately, it was simply added when the original
component was created, so I'm not sure what its use was.
When a user restarts a job, we should not try fetching the log again. In
order to do this I added a guard in job-log component, which checks if
attributes changed in didReceiveAttrs callback. If the old job value is
the same as the new value, we don't need to do anything.
