For some reason uflify fails on regular ember.js build. Using production
build fixes the problem and we should do it anyway - our assets pipeline
does some debug version cleaning, but I'm not sure if it's still
compatible with what's done when generating Ember's production build.
After changes in travis-core, irrelevant headers are removed when matrix
is expanded. For example python version is removed from a ruby build.
Build's config is not altered, so in order to get only effective keys,
we need to iterate over jobs.
For some reason (I haven't had time to debug it) when we don't use named
outlet rendering "into" does not work in certain circumstances (for
example in index current view, where repos are changed automatically).
This commit contains a settings pane implementation. There are a couple
of things here, which are not used yet, like advanced form helpers. I'm
leaving them here, because the plan is to add support for more settings
soon (like: include/exclude branch patterns), which will need these
helpers.
There is also tabs support, although in the current version there is
only one tab (initially it was created for supporting general tab and
notifications tab).
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.
