Why do we have Angular vendor deps checked in?

[dhermes]

[dhermes]

e.g. https://github.com/GoogleCloudPlatform/gcloud-python/blob/master/docs/json/src/vendor-7173ada14e.js

[daspecster]

The gcloud-common doc site runs on angular.
This is the standard way that you deploy the doc site AFAIK.

Alternatives would be to pull the link in from a CDN but then you would have to track which versions are being updated and used by gcloud-common/site each time you deploy.

This file should contain all vendor related JS so that there is less HTTP connection overhead. i.e. one JS file to download instead of however many libs you use.

Not sure if that's the answer you were looking for or not?

[dhermes]

Why doesn't it get pulled in with gcloud-common?

[daspecster]

Right now the files are getting staged in doc/json. Which makes it easy for testing (python -m SimpleHTTPServer).

We could make it more automated and have the deploy script pull in gcloud-common and do a gulp build then copy the files over. But we would have to setup all the dependencies for that in travis.

These could live in the gh-pages branch permanently. That's what the other projects do.
I just don't feel like gh-pages is very permanent so I build everything from the main repo, package it up and then deploy it to gh-pages.

[dhermes]

I am out of my element here, do what you think is right, just don't want our hardcoded files to drift from the ones in gcloud-common

[daspecster]

These are generated from gulp build in gcloud-common so I'm not too worried.
The process to update them is to do the gulp build and then copy over the dist/src folder that's generated.

The ideal solution IMHO, would be have travis do a new build of gcloud-common/site with each doc deploy and gcloud-common/site had changed since the last deploy of gcloud-python's docs. Not sure how to track that though.

[dhermes]

You just need to write a script to check out gcloud-common on Travis and gulp build. You can utilize Travis caching to make this more efficient if you like.

That way you don't have to worry about drift and we don't have files in our repo which aren't part of the build.

Having to update them on a regular basis seems a bad idea.