Is it possible to auto-deploy to AppEngine when Github receives a new commit? I found a bunch of dead documentation links that suggest it is, however I still have no idea how to set it up. There are some mentions for creating a release pipeline, but I don't see any way to do that in the cloud console anymore.
I've got my code mirroring the GitHub repository already, however I can't figure out how to link this to the deployment pipeline or even how to create a new version. Am I missing something obvious? This seems like it should be incredibly straightforward to do...
The entry on the Google Cloud Platform blog that's supposed to explain how to achieve this is blank. It seems Google quietly killed this feature. Some people have complained that it suddenly stopped working. The only way to do this now is to use Continous Delivery/Integration tools such as Travis CI.
Related
I've been working on a small Google App Engine (standard environment) project that uses Cloud Endpoints v2. My code is largely based on the quickstart provided by Google.
Everything was working fine, but I re-deployed today after having not looked at it for a few weeks, and I'm getting the following error when I attempt to call the endpoint:
error: An error occured while connecting to the server: DNS lookup failed for URL: metadata.google.internal
This wasn't happening before. It seems to be happening when the endpoints package is being imported by Python.
My endpoint doesn't do anything fancy - I haven't changed the source from the sample EchoApi. The error ends up in the GCP Logging console no matter if I try to access the API through the API Explorer or via Curl.
I don't get any errors during deployment.
Edit #1
Some further information:
The error originates from within Google's code that is included with the google-endpoints package which I've included in my lib folder, per
the documentation. Specifically, the error occurs on line 54 of google/api/control/wsgi.py.
Basically, it's making a request to metadata.google.internal using urllib2.
I'm guessing this address is only available from within the Google Cloud, and that for whatever reason, the instance that's hosting my app can't do a DNS lookup on it.
Edit: #2
Dug a bit further.
It seems that the error originates in the google-endpoints-api-management package. Changes committed to that package on October 19th seem to have introduced additional platform reporting. metadata.google.internal is queried to check if the code is running within the Google Container Engine, then it blows up, because the metadata address doesn't resolve.
Here's the commit:
https://github.com/cloudendpoints/endpoints-management-python/commit/0a37d0e443091053ed03e455e06d3a0ae770999f
The google-endpoints package only requires google-endpoints-api-management >=1.0.0b1. On my end, things were working fine on version 1.0.0b2, but then I built a new lib folder, which brought down 1.0.0b5, and things went sideways. Required packages haven't changed between b2 and b5, so I'm thinking I may be able to just downgrade back to b2 for the time being. Haven't tried it yet.
Sent the Google Dev an email. Perhaps he'll chime in with further tips.
Edit: 2016-11-07
Tested downgrading the google-endpoints-api-management package to 1.0.0b2. Seems to be working, kludgy a fix as it is. If you're using the lib folder, the following will scrub the newer error-prone wsgi.py file and put back the older one:
pip install -t lib google-endpoints-api-management==1.0.0b2 --upgrade
Not pretty, but it may just get you back in business.
On a side note, the Google engineer promptly replied saying that he would take a look at this issue soon. With luck, endpoints v2 will eventually come out of beta, 'cause I'm really liking it so far.
This will be fixed in an upcoming patch to the google-endpoints-api-management package (which will be 1.0.0b6). It will probably be released sometime on Monday, 11/6.
If you'd like to continue testing right away and this error is blocking you, you can go back to 1.0.0b4 until 1.0.0b6 comes out. Everything should still work as normal with that version.
Thanks for bringing this to our attention! We're doing our best to iron out all of these wrinkles now during beta in preparation for our first general release.
EDIT: 1.0.0b6 has been released and resolves this issue. Thanks for your patience during our beta phase!
(Posted solution on behalf of the OP).
Google has released version 1.0.0b6 of the google-endpoints-api-management package to address this issue. It solved the problem for me. For anyone who is encountering this problem, clean out your lib folder and re-install the google-endpoints package. This will bring down the new google-endpoints-api-management package with it.
Thanks to Brad at Google for really quick action on this.
I was running two different versions of my app with the same api_version number, and I started receiving Database locked exception. I've closed both apps, removed both from the app engine launcher, and then reloaded the one i'm currently working on; and I'm still getting the same error.
I've been googling it for 30 minutes, and it doesn't seem like there is a lot of information on this topic specifically related to GAE.
I would like to know how to go about fixing the issue, but more than that, I'd like to know what's causing it in the first place.
I gave to 2 api versions different version numbers but the same api number with the hope that I'd be able to run them concurrently and have them share a datastore instance, but if its displaying this behavior locally, I'm sure its not going to work when deployed. I suppose I have less of an understanding of the versioning than I thought. If anyone has a brief explanation of that process, what causes locking and how to fix that would be great. Thanks!
EDIT:
'api_version' refers to google's api for app engine; nothing to do with one's personal application. still trying to figure out how to deal with 'version' and #endpoints.api. What's the diff?
Google app engine refuses to deploy my latest build, and looking at the releases list, I can see that another build has been 'deploying' for the better part of a week.
Google doesn't offer support anymore for this without paying for it, but this is stuff that just shouldn't happen.
Hope one of you google engineers out there can help me with this. The google project is caleld vxlpay.
Have you tried doing an appcfg rollback?
Please cancel the deployment if it gets stuck; just waiting for it to finish often leads to frustration and desk-flipping. There's a few ways to help you deploy the app.
1) Generally, you can simply redeploy after waiting a few minutes.
2) Redeploy with another deployment method (appcfg, Google App Launcher, Eclipse...)
3) Rollback then redeploy
If all 3 fails, there might be something wrong with your configuration and you would probably need to speak to the support engineers at Google.
I ran into to this just now.
I think my issue had something to do with having a browser open to the site I was trying to deploy to. Apparently that was locking up a process or something because, when I closed it, my deploy finished.
Silly, yes. I think it has something to do with GAE attempting to migrate traffic but not dealing with cases where there's browsers open... There's probably a feature that allows for deploying and controlling whether or not traffic is migrated.
I'll have to give that a try to see if closing the connection (browser) resolved it or if it was just a timing thing.
Nope... Just takes an absurdly long time.
Maybe it's due to file sizes?
Note: This only occurs when deploying a Flex environment rather a standard one.
I am using this link to build a simple chat application using GCM, and I found this great feature "Google Cloud Endpoints" which makes things easier. But I am afraid to depend on it as I noticed it is still experimental. Can I trust it or should I use Java Servlets instead?
It is true that the tag 'experimental' is a bit scary. If you are concerned, you could consider holding back a bit until Google IO 2013, which is the middle of May. They often make announcement and introduce new technologies there.
They first announced endpoints at last years' Google IO (in July) and if there any significant changes pending for endoints they would likely announce them at this years'.
If you do start using Endpoints, just for Android, and w/o user authentication, I don't think it would be too hard to revert to using a Servlet instead, if you had to (i.e. due to a change in terms that was off-putting). The user authentication stuff would be harder to replace IMO.
As far as I have used Google Cloud Endpoints they work perfectly. Furthermore many interesting features are already implemented, such as integration with Google Eclipse Plugin and testing through the Google APIs Explorer, even in localhost, using the Development Server.
I understand they're still experimental maybe because they're just a new technology not really thoroughly tested yet and are subject to updates. Anyway I've not found significant bugs so far and you should be able to reuse your endpoints with the sucesive versions that will exist. It doesn't seem to be something that will dissapear in the near future...
This is an older question, but for further references I want to say that my short experience was not so pleasant.
I tried "Mobile Backend App". In the beginning, everything worked fine, but after a few days (without changing anything) I received:
GoogleJsonResponseException 404 Not Found
I sow other posts on stackoverflow and manage to solve it by creating another project. I changed the code and it still worked. But again I had problems I played a bit with the 2 projects, I redeployed and changed the settings (tips found on other posts) and it worked. Now it is no longer working, no matter what I do.
I hope that the problem is specific to this project, but nevertheless it is frustrating.
I got Error 500 on Google App Engine out nothing.
http://oladic.appspot.com/ - this got error.
The same code runs flawlessly at:
http://blogthere.appspot.com/
and
http://912.latest.oladic.appspot.com/
How could this be?
This issue has been resolved. The post on the downtime-notify list is here:
http://groups.google.com/group/google-appengine-downtime-notify/browse_thread/thread/7fb8a39149de3b55
The update on the system status page is here:
http://code.google.com/status/appengine/detail/datastore/2010/02/02#ae-trust-detail-datastore-get-latency
You can see the System Status and check if the error was when the system had problems
I had this problem for 2 days, turns out it because I'm not listed on Google's "Trusted Developers List?" My only issue now is why Google doesn't return a meaningful error message..
Here's their own thread on the matter. See for yourself.
http://code.google.com/appengine/forum/go-forum.html?place=topic/google-appengine-go/zdMysT6yO30
App Engine appears to be borked this morning, lots of people are having this problem on the mailing list as well.
My site has just, somewhat unexpectedly, come back online, with no work done by myself.
I assume it was a temporary problem with the App Engine, and, with any luck, your site should come back up soon.
In my case, the problem appeared when I decided to deploy the application. After inquire for a while, I figured out that the problem was being caused due the imports of simplejson (in MacOS) or json (in Windows).
The solution to this, is to import the libraries from django. In my case I did:
from django.utils import simplejson
I hope this solution will work for you.
I had a similar problem, and like Harph above i eventually realized that the use of a JSON module via the following import:
import json
was the cause of the error (at the Engine side) -something that was not problematic at the development server
I corrected this to
from django.utils import simplejson
And this has solved the problem.
thanks Harph for the tip.
Note: Another very important thing that I'd overlooked, that might actually make it harder for other devs working with the GAE for the first time, is not using the Error Logs in the Admin Console (at the datastore admin interface). This is i believe the surest way to quickly pin down the cause of problems at the GAE side (especially ones you don't see at the development server).