Publish jar for cel extension

[jaydeluca]

Description:

@laurit pointed out that we are not publishing a jar for the new cel sampler.

I've added the extension jar creation here, as well as an integration test.

Testing:

Integration tests that use a basic app and package and test the CEL sampler functionality

cc @dol

[jaydeluca]

I copied this from the GCP auth extension as-is
https://github.com/open-telemetry/opentelemetry-java-contrib/blob/5809da024bf450aa388d37a7ca2c398c2ca2cac0/gcp-auth-extension/build.gradle.kts

[zeitlinger]

great 😀

[zeitlinger]

using FROM is more cache friendly and renovate works out of the box

[zeitlinger]

see https://github.com/grafana/grafana-opentelemetry-java/blob/bad369155b754fdb36887fc2082bb283ecdb76be/Dockerfile#L7

[jaydeluca]

i might be misunderstanding something, but what would i be using as the base image using "FROM"? this is pulling the agent

[zeitlinger]

yes, that also what the example does.
it's then copied in https://github.com/grafana/grafana-opentelemetry-java/blob/bad369155b754fdb36887fc2082bb283ecdb76be/Dockerfile#L62

[jaydeluca]

the grafana one is pulling a docker image, it is not pulling the agent directly.

Doing something like this doesn't work/make sense since it isn't a container:

ARG OPENTELEMETRY_JAVA_INSTRUMENTATION_VERSION=v2.22.0
FROM github.com/open-telemetry/opentelemetry-java-instrumentation/releases/download/$OPENTELEMETRY_JAVA_INSTRUMENTATION_VERSION/opentelemetry-javaagent.jar as agent

I'm not aware of a container I could use to pull with the agent, and I'm not sure if it would be beneficial compared to just pulling it directly like this?

[zeitlinger]

• image: https://github.com/open-telemetry/opentelemetry-operator/pkgs/container/opentelemetry-operator%2Fautoinstrumentation-java
• why: the docker layer can be cached and renovate knows how to update

[zeitlinger]

what's that needed for?

[jaydeluca]

was getting this:

[oats-tests] $ ~/work/opentelemetry-java-contrib/opentelemetry-java-contrib/.mise/tasks/oats-tests.sh
/home/runner/work/opentelemetry-java-contrib/opentelemetry-java-contrib/.mise/tasks/oats-tests.sh: 4: set: Illegal option -o pipefail

[dol]

@jaydeluca Sorry, for being late to the party. I was experimenting the last few days on a proper setup on how to distribute the shadow jar of the cel-sampler, which took longer than expected.
As per legal requirement, the license agreement of the distributed dependencies should be checked before each release or dependency update. The PR #2518 tries to detect the licenses of all direct and transient dependencies and compares it to an allow list.
It also adds the SBOM and all the third party license agreement to the uber/shadow jar. This way all the legal obligations should be met.

Your PR adds the shadowJar bundling capability and an integration test to the cel-sampler. I agree, that an end2end integration test is missing. As

opentelemetry-java-contrib/gcp-auth-extension/build.gradle.kts

Line 70 in b7a3272

val integrationTestUserCreds by registering(JvmTestSuite::class) {

already provides a good base for an integration test, I would take a similar approach and would do an implementation in pure Gradle and Java. From a developer perspective it's now required to have the docker, docker compose and mise tools installed to run the integration tests.
This might spark an overall discussion on how to do end2end tests. Eg. #2119 follows a slightly different approach.

For the shadowJar bundling I would wait how the discussion in #2518 unfolds. Depending on the outcome it would be ideal if the integration tests could based on the proposed shadowJar convention.