Can you test an uploaded version of an app, other than the "default" version?
I'm told it can be: WoLpH Google App Engine version numbers?
But I can't find it in the dashboard or the doco.
If the version of app is 2 and your app URL is appname.appspot.com then URL 2.appname.appspot.com will give you access to version 2 of your app.
As Vishal already said correctly (+1), you can prepend the version identifier to your url, so if your version is "version", the URL will be version.appname.appspot.com (app versions are strings, not numbers, although the string "2", is perfectly ok too).
To select another version from the Dashboard, just select the main application first, then use the second dropdown at the top of the page to select the version. This will show you the dashboard of another version, without changing the default (active) version.
Important considerations to keep in mind:
However, the main gotcha that I would like to mention, is that you're using the same Datastore of the live version. This can be a good thing, if you want to browse your application, but is not very recommendable if you want to insert test data that could potentially mess the public view.
You're also using the same task queues and cron, so you've to be careful of unintended consequences, should your application version update them.
If the problems mentioned above are important to you, you may consider to deploy another application to use for testing instead. In this way you'll be completely separated by the live environment.
Note that double wildcards for appspot.com are no longer supported (*.*.appspot.com). To test different version than default use version-dot- prefix.
appname.appspot.com // default
2-dot-appname.appspot.com // version 2
In the menu there is section Main > Versions and there you can choose the version then "Make default". Of course to have more than one version available there you have to change the version before deploying(as far as I remember you can do this in one of xml files).
Or you mean to have default version, but test another one?
Related
This question is related to an issue when running a Python 2 and Python 3 version of an application with split traffic that uses the Task Queue.
Looking at the taskqueue.py module, I've gathered that the target for the Task is set to the DEFAULT_APP_VERSION, however I do not know how this is determined when two versions of the app are considered the default version.
As of the moment, there is no option to determine or select the default version of a service when traffic is split. The only thing I could observe is when traffic is 100% allocated on one version, that would be considered as a default version, since I am unable to delete it.
Before there was an option to just select the default version when you create multiples of it but it was no longer available. Link for the document here.
When I migrate all traffic to another version, it would change to [project-id].[region].r.appspot.com. I would consider this to be the default version as no other versions are being used and no traffic is being split.
You can check out the definition of target wherein:
Push tasks only; specifies the alternate version or backend on which to run this task, or DEFAULT_APP_VERSION to run on the application's default version. You can specify a module or version, a frontend version, or a backend on which to run this task. The string that you specify will be prepended to the domain name of your app. If you specify the target argument, do not specify a Host header in the dictionary for the headers argument.
Link for the taskqueue documentation through this link.
If selecting the default version is badly needed for your project, I would suggest filing for feature request. This is not a guarantee that it would be available in the future but it's worth a shot.
I have just started a new site where I am using 2sxc version 11.11.4 (started with 11.7.3 and upgraded to see if that would fix it). I have the data and views set up just like I have done on another site using version 10.25.2. On the newer version though, I'm unable to use the remove button/action. I did some searching and found a few references to adding lines to the web config file (https://github.com/2sic/2sxc/issues/1654, https://github.com/2sic/2sxc/issues/2205). I tried this and it worked great.
So, my question: will a fix be implemented for this or will we have to add these lines of code to the web config file on any site we use 2sxc on?
Also, could these lines of code affect any other DNN features, other modules, etc.?
I think you are talking about my solution here
https://github.com/2sic/2sxc/issues/2205#issuecomment-705647892
This is specific to a server where the WebDAV features have been added/enabled in Windows. I do not think its an issue that can or will be fixed in 2sxc.
I do know that it is safe to add those two items in web.config. All its doing is telling ASP.NET to NOT make WebDAV available in this application's (DNN's) context. I am not aware of any DNN feature or modules that need or use WebDAV. Its just something handed down from the server because its installed and its causing a weird change in behavior that makes the DELETE (and other) command types get ignored (IMHO, presumably because they are handled before they get to DNN).
I am working on Adobe CQ. I created 2-3 versions(1.2,1.2,1.3) for a particular page in my author instance. Now I tried to package my content page and installed it in another instance. I couldn't see the versions of the page which I installed in another instance.
Can anyone help me out doing this?? I want to migrate my content pages along with their versions from one CQ instance to another??
We are in the same situation. You can extract prior version details using the packaging approach, but you will be precluded from reloading them in due to the new Oak security model. The next issue is that you would need to extract and transform the data, and then reinsert due to the node ID's potentially differing, especially if you are using partial data sets to extract.
Where we have gotten to, and are proving now, is to use the new migration tool to move content from instance to instance, which purportedly has a version extract tool. I will update details here when we get our results back.
UPDATE:
We have tested the CRX2OAK migration tool, and it indeed does move versions across. Using the tool, you can specify filters to only migrate a subset of content, which will then drag the version details across as well.
It seems this approach works quite well for both single tenancy and multi tenancy approaches as it used to using a package for content.
Unfortunately, it can't be used as a portable backup system, as it is an instance to instance solution. It does, however, work well for blue/green deployment strategies.
Versions are stored by path '/jcr:system/jcr:versionStorage' in AEM.
To transfer pages with their versions just create a package with filters for content which you want to move and the version storage path as well, download package and install in other AEM.
If anyone comes across this question like me, here is the summarised answer:
You can use crx2oak utility available from link below to migrate pages and page version across instances:
https://repo.adobe.com/nexus/content/groups/public/com/adobe/granite/crx2oak/
This is a powerful utility with multiple uses (especially in upgrades) as documented in links below:
https://docs.adobe.com/docs/en/aem/6-2/deploy/upgrade/using-crx2oak.html
https://jackrabbit.apache.org/oak/docs/migration.html
The source and destination repositories need to be offline while running this utility so best to plan ahead for this type of migration.
HTH
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
I want to test my thick client against my RESTful appengine application. I regularly increment the appengine version number so I need to keep updating my test config. Is there the equivalent of http://latest.application.appspot.com that I could point my config too?
Thanks
Skirting around your question, but in my head, I've stopped thinking of the "version" in the typical software release version (which like you, I started out thinking), but rather, it's "a different application using the same datastore".
I found out the software release version (1.0, 1.1, 1.2 etc) doesn't make much sense because 1) I don't tend to use older versions 2) my main usage would be to regression test, but this doesn't work well, because it's quite possible for a change in your model in v1.1 to break the code in v1.0.
The versions feature comes in hand to have different functional versions. For example, maybe the default application.appspot.com runs production level code, but debug.application.appspot.com has more logging enabled. Perhaps a third version has administrator functionality enabled, etc.
No, there's no way to do this. Versions aren't sequenced - they're all entirely distinct deploys, only one of which is set as the default.
What you are likely looking for is the CURRENT_VERSION_ID environment variable. It stores the deployment revision as dot-separated string: version_name.deployment_revision, e.g. staging.12345678910111213141516. You could just use it directly in your config:
import os
API_VERSION = os.environ['CURRENT_VERSION_ID'].split('.')[1]