Tests fail on Debian buster on jenkins

We will want to move metrics services to the new Debian stable, but currently metrics-lib does not pass tests on the new release.

https://jenkins.torproject.org/job/metrics-lib-master/ARCHITECTURE=amd64,SUITE=buster/1/console

added component::metrics/library owner::metrics-team priority::high resolution::wontfix severity::normal status::closed type::defect labels

Trac:
Description: We will want to move metrics services to the new Debian stable, but currently metrics-lib does not pass tests on the new release.

https://jenkins.torproject.org/job/metrics-lib-master/116/console

to

We will want to move metrics services to the new Debian stable, but currently metrics-lib does not pass tests on the new release.

https://jenkins.torproject.org/job/metrics-lib-master/ARCHITECTURE=amd64,SUITE=buster/1/console

Looking into this now.

Trac:
Status: new to accepted
Owner: metrics-team to karsten

Alright, I fixed the builds on buster and bullseye and broke the build on stretch. The reason is that we're specifying libraries by version and the latest versions in buster and bullseye are not available in stretch. Maybe we should just kill the stretch build?

Java: write once, run anywhere (as long as it's exactly like my dev environment)

We should kill the stretch build, but this does leave us with the issue that we need the JAR to run on stretch even if it doesn't build on stretch. This is probably solved by making sure that the buster build is using the same version of the JDK as is in stretch, which may not be default-jdk.

Replying to irl:

Java: write once, run anywhere (as long as it's exactly like my dev environment)

Heh.

We should kill the stretch build, but this does leave us with the issue that we need the JAR to run on stretch even if it doesn't build on stretch. This is probably solved by making sure that the buster build is using the same version of the JDK as is in stretch, which may not be default-jdk.

We wouldn't switch to a newer Java version at this point. I wouldn't even start building releases with another JDK version. I'd just copy over the new libraries from a buster machine to my macOS build machine and continue building with whatever JDK version I have here.

Let's reconsider our options here after getting the CI running on GitLab. Maybe the best way forward is to just kill all Jenkins jobs. If not, we'll want to update the jobs to use Ivy to resolve external dependencies.

I think using GitLab CI is better than Jenkins for what we use it for. We don't necessarily need to trust the output. It's a tool that helps us but if it lies to us it's not a disaster. We're also not giving it any dangerous secrets.

We also have the advantage that we'll be able to run CI on merge requests. I need to do more configuration for that.

Sounds great to me. Unassigning from myself and reassigning to metrics-team to reflect that I'm not currently working on this.

Trac:
Status: accepted to assigned
Owner: karsten to metrics-team

We just said that, now that we have CI for all metrics code bases including metrics-lib, we can kill the Jenkins job for metrics-lib, including the buster one. That should be an easy fix.

Created #31883 (moved) for the sysadmin side of this. Nothing more to do here, closing.

Trac:
Status: assigned to closed
Resolution: N/A to wontfix

closed

mentioned in issue #31194 (moved)

mentioned in issue #31347 (moved)

mentioned in issue tpo/network-health/team#109 (closed)