Repository navigation
Avoid downloading gcd.sh if cloud SDK is availble #123
Description
Cloud SDK now supports running a local datastore by invoking gcloud beta emulators datastore.
If we detect that gcloud is available we should run the datastore using it rather than fetching/caching and invoking gcd.sh
Activity
mziccard commentedon Sep 14, 2015
Having a look at this I noticed that
gcloud beta emulators datastoreruns the datastore with no--allow_remote_shutdownoption and I could not find a way to provide it. This might be a problem for us as we use thePOST /_ah/admin/quitAPI to shutdown the datastore emulator once the tests are run.Shall we ask for that option to be added to gcloud (It's a really small change)?
jgeewax commentedon Sep 14, 2015
pcostell commentedon Sep 14, 2015
Yes we should -- I can file a bug internally, or someone can file a bug against the gcloud SDK. It wasn't left out intentionally, it just wasn't prioritized.
Also, you can work around this by using the gcd tool directly
$GCLOUD_PATH/platform/gcd/gcd.shSomething to consider -- it may be worth pinning the version of gcd you use for development. Otherwise, tests on one machine may act differently than tests on the other.
mziccard commentedon Sep 14, 2015
Thanks @pcostell, I'll file a bug against gcloud SDK then.
I think the point of using
gcloudwas to let it handlegcd.shinstall and update (and to avoid multiple downloads). But while the--allow_remote_shutdowngets added we can go for callinggcd.shdirectly ($GCLOUD_PATH/platform/gcd/gcd.sh) if installed. Any thoughts @aozarov?pcostell commentedon Sep 14, 2015
Just a random note, I think you should just use --testing. I believe it includes --allow_remote_shutdown as well as a bunch of things designed to make unit testing easier.
aozarov commentedon Sep 14, 2015
Yes, that sounds good (or we can try the
--testingflag and see if that works).However to @pcostell point, one benefit of the existing code is that LocalGcdHelper is pinned to a specific gcd version that it is known to work with. I still think we should leverage gcloud SDK if exists but
we should find a way to verify that its local datastore version matches as well. @pcostell is there a way for us to do that?
pcostell commentedon Sep 14, 2015
It looks like
gcloud versionlists which version of the emulator is in use and includes the API version.mziccard commentedon Sep 14, 2015
@pcostell Do you mean
--testingas an option togcd.sh? As far as I know it does not include--allow_remote_shutdown(even though I would like it to :)@aozarov I run the tests with gcd v1beta2-3.0.0 and they are passing.
aozarov commentedon Sep 14, 2015
Great, I was expecting that. I think the LocalGcdHelper needs to check that gcloud SDK gcd-emulator prefix is v1beta2 before deciding to use it.
pcostell commentedon Sep 14, 2015
@mziccard you're totally right, it isn't included. Perhaps we should consider including it.
aozarov commentedon Sep 18, 2015
Fixed in #162
7 remaining items
deps: update dependency google-auth to v2.12.0 (#123)
chore(main): release 0.5.5 (#104)
chore(main): release 1.1.3 (#123)
chore(bazel): update protobuf to v3.21.7 (#123)
chore: require hashes when installing dependencies in owlbot postproc…
chore(deps): update dependency com.google.cloud.samples:shared-config…
chore: regenerate README versions (#123)
ci: enable GitHub actions (#123)
Merge pull request #123 from google/shinfan-dev
chore(deps): update dependency com.google.cloud.samples:shared-config…
Merge pull request #123 from google/shinfan-dev
chore(deps): update dependency com.google.cloud:libraries-bom to v5.2…
build(java): skip lint on samples directory (#123)
build(java): skip lint on samples directory (#123)
chore: fix renovate config (googleapis#123)