[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Pondering sunsetting the Jenkins CI and repo for dpkg



Hi,

Nobody did answered.

I could have used "deb https://jenkins.grml.org/debian dpkg main"
but it seems a lot of work to maintain compared to my little use.

Thanks for asking

Greetings

Le sam. 9 mars 2024 à 18:29, Guillem Jover <guillem@debian.org> a écrit :
>
> 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
>


Reply to: