[BEAM-177] Upload JaCoCo coverage data to Coveralls from Travis-CI #138
Conversation
|
Example result: https://coveralls.io/jobs/13374509 |
|
The important bit is browser integration into code review. For coveralls there seems to be this. |
kennknowles
changed the title
|
The failure is in the |
| @@ -31,6 +31,9 @@ before_install: | |||
| install: | |||
| - travis_retry mvn -B install clean -U -DskipTests=true | |||
|
|
|||
| after_success: | |||
There was a problem hiding this comment.
after_success logically comes after script. Move below.
|
R: @davorbonaci Meta-comment: I'd like Jenkins to do this instead of Travis. Not sure what will happen if they both attempt to do it. |
| @@ -31,6 +31,9 @@ before_install: | |||
| install: | |||
| - travis_retry mvn -B install clean -U -DskipTests=true | |||
|
|
|||
| after_success: | |||
| - mvn jacoco:report coveralls:report | |||
|
|
|||
There was a problem hiding this comment.
Also, not sure what will happen when Travis tries to do this from its test matrix. We should probably make sure it runs just once, not 4 times.
There was a problem hiding this comment.
It runs just once, for the first job. Of course, coverage values could actually differ, but I think that is beyond coveralls.
There was a problem hiding this comment.
Explicitly running it just on Java 8 configuration, since that covers more.
|
Re: Travis vs Jenkins I don't care so much in this case. It should be fast, so it does not slow down code review waiting for results. If Jenkins is faster, then it is definitely the best choice. But I have a different stance on the meta-issue:
Jenkins has capabilities that Travis does not have:
These are compelling. We should use Jenkins for these things. But I don't see a strong reason to use it for more than that, especially since there are major downsides - no source control of config, more complex config, having to issue tickets to infra for some changes, silent back-channel changes, no review of config changes, no presubmit of config changes, no ability to synchronously alter config and code, ... For now, I'd be happy to merge PRs and get immediate benefit from Travis until our Jenkins config is offering equivalent capabilities. Perhaps it will be quite soon, but the cost is zero either way. |
|
BTW examining the latency, Jenkins is much much lower latency so we should go with Jenkins for this. Travis in the meantime. |
|
I should have remembered earlier that we can have both: https://wiki.jenkins-ci.org/display/JENKINS/Travis+YML+Plugin. Or, somewhat fewer of the goals attained via https://github.com/samrocketman/jervis |
|
PTAL. Tests pass and we can start getting some benefit for all reviews that happen long enough after a PR shows up. |
|
Please test.
|
|
The problem is this: Running the JaCoCo agent is incompatible with setting |
|
The same error still seems to occur. |
|
Yes, I did not remove the setting of |
|
I believe @dhalperi added it -- Travis build was failing without it at some point. |
Basically, to move forward, we'd have to investigate memory usage of individual tests and get it down. Then, we can increase `forkCount, and finally enable Jacoco in Travis. Given that it "somewhat works" in Jenkins right now, that Jenkins is generally preferable over Travis, that it seems easier to fully fix Jenkins than Travis, etc., I'd just probably close this pull request. |
|
SGTM. Probably a red flag that we blow memory running unit tests, though. |
|
It's actually simpler than that. Since Maven does not copy memory limits from the root process to the forked processes, Java never garbage collects (since it does not think it needs to). The VM happily grows the (non-leaking) memory until Travis kills it well before the Java memory limit is reached. |
|
I see. This can be fixed via maven config in a few ways I think. I suppose it may not be worth making the pom more complex. |
apache#135 Operator test kit accumulator validation
No description provided.