Add shadow jar and workspace controller that starts said jar #726
Conversation
Next step is to port the workspace controller from groups to use the shadow jar in a similar manner to auth, negating the need for the jars repo or a jars list
Tested in groups with the shadow jar. Needed some minor test changes but passed.
| @@ -267,10 +294,9 @@ dependencies { | |||
| ) | |||
| testImplementation 'com.arangodb:arangodb-java-driver:6.7.2' | |||
| testImplementation 'com.github.zafarkhaja:java-semver:0.9.0' | |||
| testImplementation 'org.hamcrest:hamcrest-core:1.3' | |||
| testImplementation 'commons-lang:commons-lang:2.4' | |||
There was a problem hiding this comment.
Turns out this isn't needed
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## dev-gradle2 #726 +/- ##
==============================================
Coverage 87.74% 87.74%
Complexity 5330 5330
==============================================
Files 228 228
Lines 17635 17635
Branches 2569 2569
==============================================
Hits 15473 15473
Misses 1700 1700
Partials 462 462 |
There was a problem hiding this comment.
Gotta be honest, I'm not entirely sure how to review here. I looked at the shadow jar docs (https://imperceptiblethoughts.com/shadow/) and the gradle stuff looks fine to me.
So here's the summary if I'm reading it right.
build.gradle's updated to make a shadow jar - a single jar containing the whole workspace service + docs + the new WorkspaceController.
WorkspaceController can then be invoked to stand up a temporary Workspace service to... do stuff? Does it run its own tests? Does that shadow jar get included with other Java-based services to run a temporary workspace a little more seamlessly than running, say, a Docker image?
Anyway, that looks like (from some other test module) you can just go:
final WorkspaceController ws = new WorkspaceController(params);
... do test stuff ...
ws.destroy();
which is kinda awesome.
Anyway, if that's the intent, this all seems to hit all the buttons and link together. Hitting approve, but there's a typo and a question there, at your leisure.
build.gradle
Outdated
| var BUILD_JAVA_DOC_DIR = "$BUILD_DOC_ROOT/javadoc" | ||
| var BUILD_OTHER_DOC_DIR = "$BUILD_DOC_ROOT/otherdoc/" | ||
| // This is where the DocServer will look for docs, if it changes it needs to change | ||
| // in deloy.cfg as well |
|
|
||
| workspace = servpb.start(); | ||
| // TODO TEST add periodic check w/ exponential backoff | ||
| Thread.sleep(5000); |
There was a problem hiding this comment.
Is this just to make sure that connections get made properly? Are there asynchronous things (like servpb.start()) that go off in this time that are more of a pain to monitor?
There was a problem hiding this comment.
The workspace takes a second or two to start up after ProcessBuilder.start() is called to check all the connections to other services. This just waits until it should be ready to accept connections.
There was a problem hiding this comment.
I could do a microoptimization by calling workspace.ver() in a loop waiting for it to come up as per the TODO but it doesn't really seem worth it for now
It's for cases like this: https://github.com/kbase/groups/blob/master/src/us/kbase/test/groups/integration/ServiceIntegrationTest.java#L124-L132 With the shadowjar, you no longer need to list all the dependent jars: https://github.com/kbase/groups/blob/master/src/us/kbase/test/groups/controllers/workspace/wsjars So you just add that one jar to your classpath and can easily start up a workspace to test against. Eventually I want the workspace repo to publish the shadow jar via jitpack but that's a bit farther down the road |
and it's totally awesome, thank you very much |
Tested this setup in the Groups service, replacing the workspace controller there