Docker lifecycle #433
Docker lifecycle #433
Conversation
|
cargo-jolokia-demo does not work on my local host. Master branch has same problem, so the cause is probably not this changeset. |
|
Thanks a lot ! I will check it out next week |
| @@ -17,6 +22,7 @@ | |||
| <package>org.apache.maven.plugins:maven-jar-plugin:2.6:jar,${project.groupId}:${project.artifactId}:${project.version}:build</package> | |||
| <pre-integration-test>${project.groupId}:${project.artifactId}:${project.version}:start</pre-integration-test> | |||
| <integration-test>org.apache.maven.plugins:maven-failsafe-plugin:2.19.1:integration-test</integration-test> | |||
| <!-- post-integration-test is opportunity for code coverage, such as jacoco, to collect statistics from running container --> | |||
| <post-integration-test></post-integration-test> | |||
| <verify>${project.groupId}:${project.artifactId}:${project.version}:stop,org.apache.maven.plugins:maven-failsafe-plugin:2.19.1:verify</verify> | |||
There was a problem hiding this comment.
Any particular reason why "stop" is not in <post-integration-test> ?
I ask because if you only run mvn integration-test (without verify) a server wont be stopped.
There was a problem hiding this comment.
Ok, just checked it: any extra post-integration binding goes after the default one (strange behaviour btw, would expect for pre that custom executions goes after the default and for post before).
But if you need a customization you can still bind e.g. jacoco to the integration-test phase, which then will called after the integration test but before the post-integration-phase.
I adapted the lifecycle accordingly and also removed docker:source since this is duplicated in docker:build, too (adding to the build time)
There was a problem hiding this comment.
It's documented that order of plugins is those specified by packaging, followed by order declared in pom.
Maven Failsafe, usually binds with integration-test and verify. Jacoco report-integration-mojo likewise binds to verify. So, current practice is that running and actually verifying integration tests requires using verify phase.
I was guided in my choices by what other container technologies use; Cargo recommends associating start goal with pre-integration-test and stop goal with post-integration-test. Tomcat maven plugin recommends associating run-war-only goal with pre-integration-test and shutdown goal with post-integration-test.
I would prefer not to bind jacoco:dump with integration-test. This goal must be called after failsafe runs the tests and before the container is stopped. It's often difficult to ensure the ordering of goals within a phase, particularly when parent poms and profiles are involved. You already understand the problem with binding to post-integration-test.
There was a problem hiding this comment.
I was guided in my choices by what other container technologies use; Cargo recommends associating start goal with pre-integration-test and stop goal with post-integration-test. Tomcat maven plugin recommends associating run-war-only goal with pre-integration-test and shutdown goal with post-integration-test.
That is exactly now what I suggest, too.docker:start in pre-integration-test and docker:stop in post-integration-test. My problem to moving docker:stop to verify is that you can easily call mvn integration-test which won't run verify and hence doesnt stop the container.
I know there wont be a perfect solution for the lifecycle choice, but as an alternative you could use a preStop command to get data out of the container before it stops. Or you mount the the directory where jacoco dumps its data as a volume dir within target.
wdyt, would this be ok ?
Btw, I introduced two other packagings, too: 'docker-build' for only building images and 'docker-tar' for creating a docker tar as artifact (Dockerfile + support files).
Thanks btw for the nice PR, makes things quite simpler :)
There was a problem hiding this comment.
Even after moving docker:stop to post-integration-test, calling mvn integration-test won't run post-integration-test and therefore not stop the container.
Unfortunately, mounting the directory is a non-starter in our build chain. Let me look at preStop tonight.
There was a problem hiding this comment.
Even after moving docker:stop to post-integration-test, calling mvn integration-test won't run post-integration-test and therefore not stop the container.
Yes, you are right, one would have to call mvn post-integration-test (totally intuitive ;-). Just out of curiosity : How do extract the jacoco data from a running container ?
There was a problem hiding this comment.
We use jacoco:dump to connect to port 6300.
Reviewing my personal usage of phases: mostly it's mvn clean install. For jenkins it's mvn clean deploy. If I want to build without releasing to my local respository it's mvn clean verify. I use verify because I want to look at the jacoco and failsafe reports generated from the integration tests. Occasionally while debugging an aspect of the build I might use mvn package.
I almost never use any of the really long named phases; they take too long to type and I usually mis-remember the actual name. I suspect that these phases are more about sequencing than about the expectation of use from the command line. In the Maven Introduction to the Build Lifecycle, you don't see any of the pre-*, post-*, or process-* phases mentioned until the reference section.
There was a problem hiding this comment.
ok, you convinced me ;-). I will put docker:stop to verify phase. We can still tune this if we get more feedback later on (but I want to make a release today).
The last question is whether docker:stop should be before failsafe:verify or after ? I guess before, because failsafe:verify probably stops the build in case of an error so that docker:stop wouldnt run anymore ....
Will revert to you original suggetion.
thanks :)
There was a problem hiding this comment.
Thanks for working through this with me. I appreciate the time you've taken. I'm now working with maven team to update lifecycle documentation.
Add docker packaging. This eliminates much boilerplate configuration.