Introduction of new CI system

Ben Cooksley bcooksley at kde.org
Fri Jun 16 09:00:09 UTC 2017


On Fri, Jun 16, 2017 at 10:08 AM, Luigi Toscano
<luigi.toscano at tiscali.it> wrote:
> Ben Cooksley ha scritto:
>> On Fri, Jun 16, 2017 at 9:57 AM, Luigi Toscano <luigi.toscano at tiscali.it> wrote:
>>> Ben Cooksley ha scritto:
>>>> On Fri, Jun 16, 2017 at 9:44 AM, Albert Astals Cid <aacid at kde.org> wrote:
>>>>> El dijous, 15 de juny de 2017, a les 21:45:35 CEST, Ben Cooksley va escriure:
>>>>>> On Tue, Jun 13, 2017 at 10:09 AM, Albert Astals Cid <aacid at kde.org> wrote:
>>>>>>> El dissabte, 10 de juny de 2017, a les 19:20:46 CEST, Ben Cooksley va
>>>>>>>
>>>>>>> escriure:
>>>>>>>> On Sat, Jun 10, 2017 at 5:48 PM, Luigi Toscano <luigi.toscano at tiscali.it>
>>>>>>>
>>>>>>> wrote:
>>>>>>>>> Il 10 giugno 2017 07:05:53 CEST, Ben Cooksley <bcooksley at kde.org> ha
>>>>>>>
>>>>>>> scritto:
>>>>>>>>>> Next week we will be introducing the new Continuous Integration system.
>>>>>>>>>> It can currently be found at https://build-sandbox.kde.org/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> In regards to Qt 4 support, this has been discontinued. Only KF5 / Qt
>>>>>>>>>> 5 builds are supported from this point onward.
>>>>>>>>>>
>>>>>>>>> As long as KDE Applications keeps releasing kdelibs4 and some relates
>>>>>>>>> software, as widely advertised for months with no complaints (lifecycle
>>>>>>>>> of KDE Applications 17.08), we need the old CI.
>>>>>>>>
>>>>>>>> The old CI will be shutdown as soon as is practicable following the
>>>>>>>> transition. At this point it represents a significant security risk
>>>>>>>> due to multiple issues both in Jenkins itself and some of the plugins
>>>>>>>> we run. These cannot be resolved to limitations in the available
>>>>>>>> versions of Java for the system which currently hosts the old CI
>>>>>>>> system.
>>>>>>>>
>>>>>>>> During earlier discussion it was agreed that for the short remaining
>>>>>>>> time (less than 2 months at this point essentially) we could go
>>>>>>>> without CI so I don't see much of an issue here.
>>>>>>>
>>>>>>> Did I really agree to that? It would be one of those times i surprise
>>>>>>> myself.
>>>>>> I think so, at least that is what memory says. Can't find the thread
>>>>>> where we discussed it though at all currently...
>>>>>
>>>>> Is it really that bad to leave it running for a few months more? What's the
>>>>> worst that could happen?
>>>>
>>>> The list of issues we are vulnerable to is numerous.
>>>> As shown by the frontend these include unauthenticated arbitrary code
>>>> execution in the context of Jenkins itself, account impersonation, man
>>>> in the middle vulnerabilities and CSRF issues.
>>>>
>>>> A good chunk of these are shown at
>>>> https://jenkins.io/security/advisory/2017-04-26/ but there are others
>>>> as well.
>>>
>>> So after the new jenkins is in place for Qt5 jobs, updating the current
>>> Jenkins can lead to two results:
>>> a) it still works
>>> b) it does not work anymore
>>
>> It won't work, otherwise I would have updated it.
>>
>> The newer version of Jenkins has a *hard* requirement on Java 8, and
>> the newest version of Java available in the system which currently
>> supports the existing Jenkins is Java 7.
>
> So we are not using the Jenkins LTS?

No, we had to use a non-LTS version due to the requirements of a
plugin a while back.

>
> If you can provide a base image with a newer Java, I can try to (minimally)
> port the existing code, at least until November when it will disappear.

Can we discuss this on IRC? If you are happy to invest a small amount
of time there is another approach we can use...

>
> --
> Luigi

Cheers,
Ben


More information about the release-team mailing list