Comments (19)
So the priority is to develop:
- "script" to deploy a
hello-world-servlet
style war and test that it is up and running. - the wars can be taken from a maven repo (either built locally or remotely released)
- Initially the "script" will be kicked off from a local build (perhaps a profile)
- Ideally the "script" will be kicked off from a persistent CI instance
- Once we have the script working, we can build out the number and type of wars deployed and improve the "up and running" tests to check more capabilities.
Note that as I think we need CI sooner rather than later for #7 this should be setup in parallel to the development of the test deploy "script"
Also note that I'm saying "script" as it may not necessarily be a shell script, whatever technology choice is most appropriate.
from jetty-runtime.
A few simple apps to start out with could be pulled from GoogleCloudPlatform/getting-started-java.
from jetty-runtime.
@gregw This is a high priority for us. Can someone on your side help us with this? Running these tests locally would be sufficient for now. We can later integrate them into the CI server, when that's ready.
from jetty-runtime.
What do you mean by "running these tests locally"?
Due to the nature of how gcloud operates, we cannot run locally any of these images, they have to be deployed to gcloud to test against.
The issue Greg filed was about regression testing, in an automated fashion, several known webapps.
from jetty-runtime.
Webapps present on getting-started-java
(once you fix the currently broken build on that repo)
- ./bookshelf/2-structured-data/target/bookshelf-2-1.0-SNAPSHOT.war
- ./bookshelf/3-binary-data/target/bookshelf-3-1.0-SNAPSHOT.war
- ./bookshelf/4-auth/target/bookshelf-4-1.0-SNAPSHOT.war
- ./bookshelf/5-logging/target/bookshelf-5-1.0-SNAPSHOT.war
- ./bookshelf/6-gce/target/bookshelf-6-1.0-SNAPSHOT.war
- ./bookshelf/optional-container-engine/target/bookshelf-gke-1.0-SNAPSHOT.war
- ./helloworld-compat/target/helloworld-compat-1.0-SNAPSHOT.war (appengine-web.xml present)
- ./helloworld-jsp/target/helloworld-jsp-1.0-SNAPSHOT.war
- ./helloworld-servlet/target/helloworld-servlet-1.0-SNAPSHOT.war
Do you want all of these presented as dockerized + gcloud deployables for flex only? (leaving out the helloworld-compat
webapp)
Which repo would you like to see these in?
from jetty-runtime.
What I meant by "running locally" is that instead of having a CI server run the test script, we will invoke it from our personal machines. The tests themselves would involve running the images on GCP. We can then utilize the same tests for regression testing by adding them to a CI server.
See https://github.com/aslo/java-runtimes-test for the kind of thing I have in mind.
from jetty-runtime.
Let's start out with hello-world-servlet (exclude compat). We can add the more complex apps later when the testing pattern is established.
The tests should go into this repo.
from jetty-runtime.
Looks like the various bookshelf
webapps will require some extra work.
- needs Google Cloud Logging API operational first.
- seems to require java.util.logging infrastructure at server side
- needs access to mysql backend database somewhere
This will affect the dockerized + gcloud images for:
- ./bookshelf/2-structured-data/target/bookshelf-2-1.0-SNAPSHOT.war
- ./bookshelf/3-binary-data/target/bookshelf-3-1.0-SNAPSHOT.war
- ./bookshelf/4-auth/target/bookshelf-4-1.0-SNAPSHOT.war
- ./bookshelf/5-logging/target/bookshelf-5-1.0-SNAPSHOT.war
- ./bookshelf/6-gce/target/bookshelf-6-1.0-SNAPSHOT.war
- ./bookshelf/optional-container-engine/target/bookshelf-gke-1.0-SNAPSHOT.war
from jetty-runtime.
Are the war files from getting-started-java
published in a maven repo anywhere?
from jetty-runtime.
I don't thinks so. Can we just build from source as part of the test script?
from jetty-runtime.
Just working out if a separate git repo is doable.
if those wars were published in a maven repo somwhere, then having a separate git repo is easy
or if this build / dockerize / deploy is best done within the getting-started-java
repo itself.
if this is the decision, then we'd only focus on the maven side in the getting-started-java
repo, ignoring the gradle builds
from jetty-runtime.
if we do the CI, then separate repos are possible again, as you would just have downstream builds with a local (to the CI) maven repository managing the behavior between the git repositories.
from jetty-runtime.
I'm not sure I'm following what you mean by "separate repos". Can we just keep the test orchestration code in the this jetty-runtime repo?
from jetty-runtime.
sure, but where does that test orchestration code get its webapps?
the webapps live/exist on the getting-started-java
git repository.
we could copy the source over to the jetty-runtime
repo, but that seems like a bad idea.
we could copy the webapps themselves to jetty-runtime
, but that's against google policy for including buildable artifacts in git repos, is a bad idea generally for maintenance, and is also highly discouraged by both maven and gradle.
from jetty-runtime.
The reason the example project https://github.com/aslo/java-runtimes-test works, is that everything is in one place. the webapp, the dockerfile, the deploy routines, the gcloud command line tests, the scripts, etc ...
from jetty-runtime.
I was thinking of just doing git clone
and mvn package
as part of the test script, but if that doesn't work, we can just copy the test application code over to this repo.
from jetty-runtime.
With the current split repositories, that wont work (yet).
as you cannot build jetty-runtime
with maven, as the logging
and openjdk8
artifacts (that maven itself needs) are not on a maven repository anywhere (not even a snapshot repository).
the build, using what we have currently, with no CI, looks like this.
git clone [email protected]:GoogleCloudPlatform/openjdk-runtime.git
cd openjdk-runtime
mvn clean install
cd ..
git clone https://github.com/GoogleCloudPlatform/getting-started-java.git
cd getting-started-java
mvn clean install
cd ..
git clone [email protected]:GoogleCloudPlatform/jetty-runtime.git
cd jetty-runtime
mvn clean install
cd ..
# new stuff
./run.sh
With each update to openjdk-runtime
, or jetty-runtime
, or getting-started-java
, you'd have to manually build those in the correct order to test properly.
To do this right, you need the coordination between the git repositories and the artifacts that they produce.
Currently, there's the gcr.io for the docker images (which is a bad idea!!) and the maven local repository on the users machine.
To correct this, we proposed a durable CI handle this using Jenkins (something that travis and circle-ci cannot do btw).
First: the docker images produced by the build have to be isolated for that build-chain (with the current setup/structure, if 2 people happen to build the same chain, then there's a collision at gcr.io with different images on the same names and tags).
This would be accomplished by using a build system local docker repository, with build-id based tagging (either the jenkins default of a combination of repo + branch + commit + job id, or the use of the maven expanded SNAPSHOT ids), which is handed off to the downstream builds to use.
Next, The CI would also then use a build-chain contextualized maven local repository, utilizing the SNAPSHOTS from the upstream builds as artifact references in its own build.
from jetty-runtime.
Note: the use of the maven local repository is now mandatory.
You cannot use the simple form mvn package
or mvn test
anymore with this split repository setup.
You will have to use mvn install
at a bare minimum as a replacement for building or testing.
from jetty-runtime.
Yes, I think using the local maven repository is fine, and building the openjdk-runtime first from source is ok too.
from jetty-runtime.
Related Issues (20)
- Track the Jetty request span in Cloud Trace HOT 4
- Refactor GKE cluster zone into an environment variable
- Can Logback be used for logging instead of JUL? HOT 14
- Upgrade to the latest google-cloud-logging library HOT 2
- Add JMX support HOT 2
- Spring Boot 2.0 apps fail on startup due to log4j 2.10.0 conflict with Jetty 9.4.5 HOT 1
- Broken links in jetty-runtime/README.md
- launcher.gcr.io references are obsolete in README.md
- How can I change version of jetty from 9 as 9.4 for standard environment. [(websocket )JSR 356.] HOT 3
- Custom runtime for GAE based on gcr.io/google-appengine/jetty HOT 9
- Logging Smoke Test is Broken
- CVE-2017-14062 Vulnerability HOT 1
- App Engine Flex Session Affinity HOT 10
- TraceLoggingEnhancer.setCurrentTraceId is not in correctly formatted. HOT 3
- Jetty Session Management using Memcache backed by DataStore, Enabling Memorystore for Session Management HOT 1
- Jetty to stackdriver logging with google custom logging handler HOT 1
- ContextDepth increment HOT 2
- Convert to using the dockerfile-maven plugin HOT 4
- Use Java 11 HOT 2
- Upgrade base image to Debian 10 ("buster") HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from jetty-runtime.