Pondering sunsetting the Jenkins CI and repo for dpkg

[Guillem Jover <guillem@debian.org>]

Hi!

The grml.org project has been hosting Jenkins jobs for dpkg for a long
time now, as the very initial CI we had. The jobs also generate a repo
so that people can run the latest code from git main, with the
following apt config:

  deb https://jenkins.grml.org/debian dpkg main

Due to security issues in Jenkins or continuous attacks (AFAIR/AFAIUI)
its web interface at https://jenkins.grml.org/ has been firewalled, so
it now becomes a bit cumbersome to diagnose issues that happen there
w/o having to bother someone.

I've talked about this briefly with Mika, and I while I hugely appreciate
the service that has been provided over the years (thanks Mika!), I'm
thinking it's probably time to permanently disable it (I did this the
other day as a temporary measure to stop spamming the list) given the
availability of more self-service CI systems that do not require
burdening other people, such as the one currently used from salsa (or
perhaps one from codeberg). I think the main blocker might be whether
anyone is still using that repo?

If so, I guess we could generate one from the salsa CI too? Otherwise
I'll probably consider permanently disabling the Jenkins triggers from
the dpkg.org side and ask Mika to remove the Jenkins jobs and clean up
that repo. Objections?

Thanks,
Guillem