Opened 5 months ago

Closed 3 months ago

#31172 closed defect (wontfix)

Tests fail on Debian buster on jenkins

Reported by: irl Owned by: metrics-team
Priority: High Milestone:
Component: Metrics/Library Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by weasel)

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

Child Tickets

Change History (10)

comment:1 Changed 5 months ago by weasel

Description: modified (diff)

comment:2 Changed 5 months ago by karsten

Owner: changed from metrics-team to karsten
Status: newaccepted

Looking into this now.

comment:3 Changed 5 months ago by 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?

comment:4 Changed 5 months ago by irl

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.

comment:5 in reply to:  4 Changed 5 months ago by karsten

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.

comment:6 Changed 4 months ago by karsten

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.

comment:7 Changed 4 months ago by irl

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.

comment:8 Changed 4 months ago by karsten

Owner: changed from karsten to metrics-team
Status: acceptedassigned

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

comment:9 Changed 3 months ago by karsten

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.

comment:10 Changed 3 months ago by karsten

Resolution: wontfix
Status: assignedclosed

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

Note: See TracTickets for help on using tickets.