You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Why do we have Angular vendor deps checked in? #2134
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?
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.
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.
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.
Activity
dhermes commentedon Aug 18, 2016
e.g. https://github.com/GoogleCloudPlatform/gcloud-python/blob/master/docs/json/src/vendor-7173ada14e.js
daspecster commentedon Aug 18, 2016
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 commentedon Aug 18, 2016
Why doesn't it get pulled in with
gcloud-common?daspecster commentedon Aug 18, 2016
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-commonand do agulp buildthen copy the files over. But we would have to setup all the dependencies for that in travis.These could live in the
gh-pagesbranch permanently. That's what the other projects do.I just don't feel like
gh-pagesis very permanent so I build everything from the main repo, package it up and then deploy it togh-pages.dhermes commentedon Aug 18, 2016
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-commondaspecster commentedon Aug 18, 2016
These are generated from
gulp buildin gcloud-common so I'm not too worried.The process to update them is to do the
gulp buildand then copy over thedist/srcfolder 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 commentedon Aug 18, 2016
You just need to write a script to check out
gcloud-commonon Travis andgulp 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.
Fixes googleapis#2134. Using gcloud-common deploy-docs.sh now.
chore: skip vector search notebook tests (#2134)