Dev/70/carles show details

[txels]

This is not intended to be merged, but mainly for discussion. You can also use it to add some crude visuals to the API.

When trying to glue things together in a quick first initial story detail view, I realised the JSON data structure we are generating right now (nested dictionaries) is not ideally suited for iterating in Javascript and Angular-JS templates. See my inline comments in the PR.

We may want to come up with a properly defined and documented feature JSON data structure (and in particular all attachment info: repos, branches, build results...) before going much further.

[txels]

Instead of using our personal ones, I believe this should be the reference settings file that we use when working on code improvements for everything github/git related, which I believe is going to be most of our next body of work.

[alexcouper]

Looks nice - I get this at the moment. I guess that's because nothing has been merged into anything else yet?

[alexcouper]

We also need to handle 404s when a feature is looked up that does not exist.

At the backend, I'm putting the logic in place to return a 404. Angular needs to handle this and display something appropriately (ATM it just continues to show the spinning wheel)

[txels]

I just updated this branch with the mock-up of a more suitable JSON response, and some front-end that starts to resemble what I sketched out on paper

Run ./scripts/compile-css.sh to update the CSS and point browser to http://localhost:5000/#/features/github-70

[txels]

Forgot to mention, the focus of the discussion on this PR has shifted to getting consensus on:

• the JSON API output for a feature, here's the mock-up: https://github.com/pretenders/deploystream/pull/83/files#diff-5
• the visual output which should look as attached:

[alexcouper]

Structure seems fine to me.

Presumably additional details could be added to the details list. Not sure how we'd display that additional information since it seems we are only showing one overall colour but that's one for another day I guess...

[txels]

The main idea as described in the original google doc was: "Status/health is a single square with a color code. It represents an aggregated view of a number of indicators. Upon clicking/hovering one can see the detailed decomposition (e.g. build status, branch relevance, branch staleness, ready to deploy...) "

I will add some more details for illustration and completeness.

[alexcouper]

I think the visual side is a great start. There's a lot of white space going to be created as a result of the way the branching works, but I'm fine with that for now.

[txels]

I am sure we can try and find ways to make better use of screen, and reduce white space without generating clutter. There are a few blank ares... What white space are you specifically thinking about at this moment?

[alexcouper]

The white space to the right of the set of branches. I think in time other information to do with the feature could go there, so it's not a biggie.