Searching the docs, I found https://community.snowflake.com/s/article/jsudflibrary:
This article states that Snowflake uses the open source V8 engine. Since the V8 engine is versioned every few months, how do you determine the version of the V8 engine running in your Snowflake instance?
There is no way to automatically introspect this as of now, but if you'd like to tell without waiting on support, you can use the Chrome version history wiki page and ES Compatibility Table to find test cases to run that will tell you, e.g. —
class C {
#x() { return 42; }
x() {
return this.#x();
}
}
return new C().x() === 42;
Will differentiate v8 8.3 from 8.4.
Related
I have created a GCP Project and using App Engine standard environment for deployment purposes.
I have various developers working with me on the same project and deploying on App engine using various versions, however, we are using a default version to which all the traffic is allocated.
So are there any ways by which we can restrict the deployment on the default version. i.e we want specific people to be able to deploy on default version without removing deployment rights of other people on the same project.
And is there any alternative approach to this situation.
It depends on the runtime where you are deploying the application.
For example, in Python, if you are using the command gcloud app deploy (see the documentation), you can do the following:
gcloud app deploy --no-promote --version=<MY-VERSION-NAME>
The --no promote flag will avoid allocating all of the traffic to the version you are deploying, while the --version=<MY-VERSION-NAME> specifies the name of the version that you will create from the deployment, and replace an older one with the same name if it exists.
AFAIK there is no way to restrict deployment of a specific version. All access control method revolve around a certain identity being allowed access to deploy a certain GAE project or not. The version string used (i.e the version being deployed to in your approach) is irrelevant.
This falls into the "allows you to separate IAM roles" advantage mentioned in the accepted answer to Advantages of implementing CI/CD environments at GAE project/app level vs service/module level?.
As a note: you're attempting to implement environments at the service/module version level, which is IMHO worse than both methods compared in that post, see Continuous integration/deployment/delivery on Google App Engine, too risky?
What is meant by "staging instances" of your application in this Google Cloud Debugger doc? As per this question it seems that only the default version of an application can be used with Google Cloud Debugger. Does Google simply intend that you can use this with the default version of a separate application which you dedicate to your staging environment?
Google Cloud Debugger can be used with any module or any version of your running application. The question you referred to is obsolete.
Many projects setup a module/version or simply another project to be used as their 'staging instance' to test their code before pushing to the production instance. There is no one way to implement a 'staging instance'.
The term staging in programming mostly refers to the term development.
In the app engine, you can have multiple instances of your application. One in Production environment(one instance) and other in a Staging environment(another instance).
So production means that its a version currently running or available to the public. Staging means that it is running only for testing purposes (usually new features) before its being deployed to the public
Google saying:
You can use the Cloud Debugger on both production and staging instances of your application
Simply means that you can you the Cloud Debugger on both the Production and Staging(Development) version of your application.
I'm wondering if there is any way to run and test GAE Go apps using the standard go test || go build etc tools and if it's not possible what's the technical reason.
The Go App Engine SDK contains the standard Go packages and tools, but a modified version of them.
The GAE SDK also contains local versions of the GAE platform services API implementations which are not part of the SDK (not even the API). So you can't just use the standard Go SDK. When you build or test with the GAE SDK, the SDK takes care of a context mockup so your app will have everything (or most of the things) required to "feel" it is running in the GAE environment. The SDK also contains the sandbox restrictions that are in effect in the production environment (e.g. you can't write to local files).
Also note that some features of the GAE SDK also rely on a Python runtime (because the Go GAE SDK was created using the existing Python GAE SDK), not everything is rewritten in go.
So taking all these into consideration it would not be feasible to build/test using the standard Go SDK and it is not even possible.
I have a test app on app engine.
I incremented its version and deployed again
now If I modify some data in one version, it is written on datastore that 2nd version uses (because version point to same store)
how can I disable the version, without deleting it?
There's only one datastore that's common to all versions. It's not like each version has its own datastore.
You can set a default version, but you can't prevent anyone from directly forcing a version by going to http://version.appid.appspot.com
you could use namespaces to separate the data between versions.
https://developers.google.com/appengine/docs/python/multitenancy/overview
On my Google AppEngine (GAE) server, I'd like to do something like this:
if (thisIsTheDefaultServer)
{
// behave normally
}
else
{
// Accept special test-commands, give extra output, etc.
}
is there a way for the server code to determine if it's the current default version?
Thanks!
There's not currently any way to do this, but you might want to reconsider your requirements. Two alternatives spring to mind:
Switch on the hostname: If it's the bare appspot name or a custom domain name, you're serving as the default version. If it's a version.app.appspot.com name, you may or may not be the default version, but should probably enable the different behavior anyway.
Enable the extra behavior based on whether the user is logged in as an admin or not. This is probably a better idea all around: It makes it easier to debug your production app, and means regular users can't find the alternate version and see stuff they shouldn't.
I remember hearing the Google App Engine team mention an API to retrieve anything from the dashboard. Unfortunately, I cannot find it at the moment. I think it might have been in this talk: http://www.google.com/events/io/2011/sessions/life-in-app-engine-production.html
I did find one document referring on how to get this information exactly in Java. I did not have enough time to find the Python version.
For Java (http://code.google.com/appengine/docs/java/javadoc/com/google/appengine/api/utils/SystemProperty.html):
if (SystemProperty.environment.value() == SystemProperty.Environment.Value.Production) {
// do something that's production-only
}
String version = SystemProperty.version.get();
Checkout the available environment variables (for Java for Python )
CURRENT_VERSION_ID in the Python SDK contains the value specified in app.yaml, I think it's com.google.appengine.runtime.version for the Java runtine.