-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JaCoCo Support? #529
Comments
It is not. The buildpack is responsible for setting up the execution environment for an application, generally in production or QA workloads. Integrating JaCoCo, a development tool, into the buildpack doesn't seem to be a good fit with that goal. What use case are you trying to solve by integrating it into the buildpack instead of into your application's build? |
We use JaCoCo for test coverage metrics for unit tests at build time. We also do integration tests on deployed apps. JaCoCo provides test coverage for the integration tests performed against the running app. To do this, we're currently embedding the JaCoco Agent in the app then referencing it via e.g
Would it make sense to manage the JaCoCo agent as a framework in the buildpack? Or would this be something we should manage ourselves say in the |
How do you get data out of the agent and back to a system to visualize it? |
You can set a port to expose data from or set an IP address and the data
will be piped to the address by the agent. On Cloud Foundry we're using
the latter.
|
Then this is a reasonable choice for a framework integration. We'd expose that metadata via a service binding (probably a user-provided service in most cases). Why don't you start by putting some more information in this issue with regards to documentation about where the agent lives, what kind of configuration you currently do, documentation about how the agent is configured, etc. Let's use this issue to flesh out what the integration will look like and then we'll get on it. |
Sounds good. As mentioned, we're embedding the agent JAR in the app. Here's an example of the options we're using:
However, it may make sense to provide support for other options. Not sure if this is needed but v 0.7.10 is important for us because it "reduce[s] chance of conflict with other agents" |
Looking over the list, |
Sorry for the delay. We haven't used |
Great, that should be enough for me to get started. On another note, there doesn't appear to be a v0.7.10. |
You're correct. Looks to be a snapshot still.
http://www.jacoco.org/jacoco/trunk/doc/changes.html
|
This change adds support for publishing JaCoCo agent artifacts. [cloudfoundry/java-buildpack#529]
This change updates the buildpack to include JaCoCo agent support. [resolves #529]
@jonathanamartin You should be able to test this now. You can push an application with a bound service as documented and a buildpack specified by |
This change updates the buildpack to include JaCoCo agent support. [resolves #529]
Thanks @nebhale. I'm in an environment that has fairly stringent network policies so I'll have to see what I can do to test. I'll keep you posted. |
@nebhale I've been discussing the usage of JaCoCo as a means to analyze integration test coverage at runtime with a few colleagues where I work. There has been discussion about dev/prod parity and that we would never want JaCoCo to be used in production. That said, we could blacklist its usage through our CI/CD pipelines. However, given that we would never use it in production do you still think it's a good candidate for a |
You seemed to think so earlier, so there's at least someone who thinks its a good candidate. 😄 We have precedent for things you'd never want to run in production like Debug, JRebel, JMX, and Profiling, so adding dev integrations isn't something we shy away from. I've got some opinions about whether to integrate it, but not strongly held ones. For something like this, we'd never add it proactively, but someone asked, it doesn't harm other users, and so I've implemented it. If you are having second thoughts, there's no problem not adding it at this point. |
Since there are other dev integrations, adding JaCoCo support makes sense. It is widely used, and there do exist system and integration test cases where it would be useful to gather coverage data. |
Great. I look forward to confirmation. |
is it possible to reference this jacoco-enabled buildpack in an MTA yaml? |
I’m not an expert in SAP’s CF distribution, but since it is a certified distribution it’s supposed to be able to run all official buildpacks. As this is a branch of the official Java Buildpack, I’d expect it to work. Give it a try and let me know 😄 |
I want to try, but I'm unsure of the syntax of the mtad.yaml file to use a buildpack from a URL instead of: |
is specifying the buildpack the only thing I need? I managed to deploy an MTA with the buildpack URL of the 529-jacoco branch, but I don't see "jacoco" in the VCAP_SERVICES of the Java app. |
Buildpack syntax can take the form of a URI. So you can specify |
we will be able to override /specify sessionid correct? |
Hi All, |
@xunwu Please see the documentation |
@nebhale So do you mean that I should create a jacoco service and bind it to my application? I cannot find any jacoco service in marketplace, how can I create one? |
@xunwu I think you should be creating a User-Provided service with the appropriate credentials |
The documentation describes the payload for a user-provided service. You should use one of those. |
@nebhale Sorry I am new to user-provided service, but do I need to create a user-provided service by using " cf cups my-jacoco-service -p '{"address":"127.0.0.1","includes":"*", "port":"1010"}' " but what address and port should I use, is it the address for some jacoco microservice running on the cloud foundry? |
I used this option and see Jacoco being downloaded name: xun-javaexample So how can I grab the jacoco data on the fly? |
@nebhale This was one thing I was also wondering, If I were to deploy the receiving service on PCF itself can it be something like a go-route with port 80 or 443? Or does it need to be a tcp route? |
@shinmyung0 if you look at here http://www.eclemma.org/jacoco/trunk/doc/agent.html |
I was trying this Jacoco build pack for a while but even though I got this configuration set up in cloud foundry, and see that it has the same JAVA_OPTS as in my local, I am not able to dump the file, I set up the jacoco to dump through tcp connection and use localhost and CF_INSTANCE_PORT to dump the report on the same instance, but it got an error for java.io.IOException: Invalid execution data file.so that means cloud foundry is not allowing jacoco agent to export data? I looked at the source code, which means the output stream is not in correct format or it could be an empty output stream, I am little confused, so cloud foundry is not allowing any other process to use any port in that container? |
@jonathanamartin Did you ever get a chance to test this? |
@nebhale I apologize, facing a few roadbloack on my end and haven't been able to take the testing any further. Though, I have something in mind and will get back with you in a day or so. Thank you for your patience. |
No need to apologize. I'm buttoning down |
Hi @nebhale, I'm currently using the jacoco Buildpack and it works great - the only problem right now (really minor) is that I don't get any Session IDs, the applications are started with "sessionid=$CF_INSTANCE_ID" as intended, but the session IDs are just blank - has anyone else experienced this, or is this more likely to be a mistake on our side? Thanks! |
@Aeolic Could simply be an escaping problem. Any chance you can send over the command line (as reported by the CLI) that is run when you're successfully sending data? |
@nebhale I might misunderstand what you mean, but the command line never shows anything about jacoco sending data (I trigger a dump by using a custom TCP server and send a "dump" command to the jacoco client) - another question: Is it possible to supply port and address without using UPSs ? We have quite a lot of microservices running and right now I have to create a config for each service, because I want to use a different port for each service - Thanks! |
@Aeolic When the buildpack notices a
This is how the agent knows where to send data. I suspect that the problem is that the In 12 Factor applications, (CF is fundamentally a system for running 12 Factor applications) connections to external system are provided by the environment. In CF, the manifestation of this idea is the concept of services. So whether it's a database, an APM, or even a code coverage sink, all information of where to connect to and the credentials for connecting with are communicated via services. From the perspective of the buildpack we don't care if a service is a user-provided service or a service-broker (i.e. "managed") service, so we always start with instructions on how to use a User Provided Service to communicate this. If you find that it's very useful, you should absolutely write a Service Broker that knows how to spin up instances of the JaCoCo servers when |
@nebhale now I understand what you were talking about, the part "when you're successfully sending data" got me a bit confused :)
This is the command line we are using to launch the apps. And thanks for the other answer as well! |
OK, the problem is that the variable is called |
@nebhale I'm getting a id now, works great! Thanks so much for your help! |
I'm heading off to a conference for the rest of the week and would really like to get this merged this morning for a release, so I'm going to call this confirmed. We can always change it if there's something wrong, but I think this is sufficient for a first try. |
Thanks! |
I have a question about getting the coverage data out of CF: um, how do you do it? I've always used tcpserver mode on my (non-cloud) servers and it's fairly easy. Is it possible to configure jacoco for tcpserver mode or is only tcpclient allowed? I've never used tcpclient mode. When does it send coverage information? Reading the docs on tcpclient, it's not clear. |
For another option see #715 (comment) |
Hi
Hi Xunwu, Command I am deploying app on cloud foundry with jacoco agent support to generate test case report. |
Is JaCoCo support on the roadmap for the Java Buildpack?
The text was updated successfully, but these errors were encountered: