Cache local

[gboone]

All projects are now cached locally by the import-data script. We can version control these files and edit them independent of what's in the Team API. These YAML files also represent a filtered version of the data coming out of the API. That way, no matter what we get from the API, the data files used by the Dashboard contain only the data we're actually using.

Import public now fetches all project data from the Team API and then dumps it into a file at _data/all.json. From there we generate a YAML file for each project we intend to use in the Dashboard and generate the pages from those data files.

The advantage of this is we can experiment with the structure of the data we want to use for the Dashboard without committing the Team API team to implementing anything and we can also modify anything that comes through incorrectly from the Team API and get rid of fields we don't want like errors after we inspect them and attempt to address them wherever appropriate.

[mbland]

Travis failure due to the project count being off again.

This LGTM (Travis failure aside), but I'll reiterate that we may want to incorporate some Dashboard data structure changes into the Team API. Maybe not right away, maybe not every time, but if there are changes that'd make the API more useful for everyone we'd like to adopt them.

[ultrasaurus]

I think this approach will facilitate local testing, but I think that we should refrain from editing these files manually except in an emergency or we kind of defeat the purpose of the distributed yml files.

@gboone are you imagining Travis would check a new one into git when there is a push to production and staging would still be dynamic... or...?

[gboone]

I'm imagining we version control all these project YAML files on this repo and build the site based off of them. That way, if there's an error in the team api, we can fix or add the data in the Dashboard without holding up the Team API's process. It also gives us the flexibility to experiment without forcing every product lead to update their about.yml files just to add a bit of data we might not end up using.

[mbland]

OK, I've resolved the merge conflicts, but a question for @jeremiak: Shouldn't we call install_node_modules as part of ./go init?

[gboone]

That's a good idea, doesn't affect deployments but that way people would get the node modules installed when they run it locally.

[jeremiak]

Ya, I think we should do that!

El 22 dic 2015, a las 12:19 PM, Greg Boone notifications@github.com escribió:

That's a good idea, doesn't affect deployments but that way people would get the node modules installed when they run it locally.

— Reply to this email directly or view it on GitHub.

[mbland]

OK, done. Also fixed ./go init, as bundle_install is not a shell command. ;-)

[jeremiak]

:+1: