Issue #8 - (phase 1) script based war deployment and testing #17
Conversation
|
Consider this script and demo webapp just a P.O.C |
| do | ||
| echo "module: $module" | ||
| appengine_deploy "${module}" | ||
| done |
There was a problem hiding this comment.
It might be a good idea to remove the deployed version after the tests have run.
gcloud app versions delete "${test_runid}"
There was a problem hiding this comment.
Noted.
Do you know how to create an machine/instance (or whatever the correct name is) with a specific environment configurations? (like say 2GB or 5GB for the webapp?)
There was a problem hiding this comment.
It's possible to tweak the VMs via some settings in app.yaml. See docs. Is that what you mean?
There was a problem hiding this comment.
I'll try the app.yaml approach ...
resources:
cpu: .5
memory_gb: 1.3
disk_size_gb: 10This would be good for testing the GAE_MEMORY_MB issue as well.
There was a problem hiding this comment.
True, though if you just wanted to test that the jetty runtime obeys the GAE_MEMORY_MB env variable, you could just override that variable with an arbitrary value in a custom dockerfile, and then verify that the jvm was started with max heap set to 80% of that value.
I don't think we need to worry about testing that the GAE_MEMORY_MB value is set properly for various VM configurations; I would consider that to be on the app engine platform's side of the contract. @meltsufin Do you have any thoughts on this?
There was a problem hiding this comment.
I agree that we don't need to verify the value of GAE_MEMORY_MB because that may change. We just want to make sure that it is set, and that we are assigning 80% of it to JVM heap.
There was a problem hiding this comment.
Point is, we need to test the environment behavior as well. If we deploy in flex or not, the behavior is different, and is dependent on the memory_gb setting, so having at least the 4 different memory configurations is a good thing to test and ensure that we dont have a regression (which is the root goal of this issue and initial PR)
|
I think this is on the right track continuing what @aslo started. I like the actual tests being in Java and Maven rather than shell scripts, as long as it can be done with a reasonable amount of effort. Ultimately, we may be able to get by without using gcloud CLI at all and use APIs directly for interacting with cloud services. |
| <plugin> | ||
| <groupId>com.google.cloud.tools</groupId> | ||
| <artifactId>appengine-maven-plugin</artifactId> | ||
| <version>0.1.1-beta</version> |
There was a problem hiding this comment.
That will be a separate PR for issue #22
|
Is Alex's comment on |
|
The versions delete will come in with subsequent commit / pull request |
|
If the app doesn't successfully come up, will the test fail? |
|
Closing in favor of #45. |
This is phase 1 for the automatic deployment of webapps and integration testing against the jetty9 base image.
More webapps and cleaner integeration testing will be subsequent phases.