Travis CI still uses an Ember client that is based on an architectural mess which I have hacked together in last September or so and it is still using the old SC routing stuff and (a hacked version of) SC datastore. This is probably (part of) the reason why the current client behaves weird in some situations and entirely stalls in recent Chrome versions under heavy load.
I want to rebase/reimplement the client based on the current Ember routing stuff and architectural ideas, ideally preserving its functionality.
At some point we separated assets out of the travis-ci web app (which mostly serves the JSON API, does authentication, etc) into a travis-assets repo which both ties into the web app (travis-ci) as a railtie for development AND is deployable to an asset host as a Sinatra app.
This setup uses a customized Rake::Pipeline and is watched/recompiled using Guard in development. It keeps previously deployed asset versions and serves the current version through http, so that it can be queried and updated by clients (two apps, travis-ci and travis-hub) periodically.
I would like to improve this setup as the Rake::Pipeline recompilation behaves sluggish during development and I am not happy with our heavy customization.
I would ideally like to keep travis-assets separate from travis-ci but that's not a hard requirement. The only hard requirement here is that it should use an asset host and keep asset compilation out of the deployment in order to reduce deployment times.
The app uses two different "layouts", the main/default layout which has a left, right and main column (1-6) and the profile layout which (currently) only has a single main column (7).
- https://skitch.com/svenfuchs/ebjck/travis-ci-root-url
- https://skitch.com/svenfuchs/ebjcg/travis-ci-repository-current
- https://skitch.com/svenfuchs/ebjcb/travis-ci-repository-history
- https://skitch.com/svenfuchs/ebjci/travis-ci-repository-build
- https://skitch.com/svenfuchs/ebjcs/travis-ci-repository-job
- https://skitch.com/svenfuchs/ebjc6/travis-ci-search
- https://skitch.com/svenfuchs/ebjc4/travis-ci-profile
The profile page layout is currently rendered on the server side and it only uses Ember to populate the repository list there. I'd like to focus on getting views 1-6 right, but it would be great to have a concept of "layouts" so I can later implement the profile page in Ember, too.
All of the entities involved in screens 1-6 are loaded from the JSON API but also can be updated through websocket events (using Pusher).
Screens 1 and 2-6 behave different in how the repository is retrieved. On the root url (screen 1) the repository view (main column) "follows" the most recent repository from the repository list (left column). On screens 2-6 the repository view sticks to the repository referenced in the url. Screens 1 and 2 both follow the most recent build of the given repository, whereas screen 4 will stick to the build given in the url.
The tabs "Build" and "Job" are not visible on screens 1-3. "Builds" is visible on screens 4-5, while "Jobs" is only visible on screen 5. These tabs are linked to the respective [repo]/builds/:id or [repo]/jobs/:id urls.