On 07. 11. 19 16:26, Fabio Valentini wrote:
On Thu, Nov 7, 2019 at 10:14 AM Miro Hrončok
<mhroncok(a)redhat.com> wrote:
>
> On 07. 11. 19 9:55, Fabio Valentini wrote:
>> On Thu, Nov 7, 2019, 09:25 Miro Hrončok <mhroncok(a)redhat.com
>> <mailto:mhroncok@redhat.com>> wrote:
>>
>> On 06. 11. 19 23:10, Randy Barlow wrote:
>> > On Wed, 2019-11-06 at 21:32 +0100, Miro Hrončok wrote:
>> >> Is there any good way to get notified about this sort of problems
in
>> >> timely manner prior to the update being pushed? This is currently
not
>> >> optimal.
>> >
>> > I'm not familiar with an existing solution to this problem, but I
agree
>> > that it is not optimal.
>> >
>> > I had a chat or three with Brian Stinson about some ways we could
deal
>> > with problems like this. Today, when we CI packages (i.e., Bodhi
>> > gating), we typically just run the tests associated with the package
>> > being altered. Brian suggested that we could *also* run the tests of
>> > the packages that depend on the package being altered, against the
>> > altered package. This way if a change to something (like pyramid)
would
>> > break a dependent package's tests (such as cornice), then the
update
>> > for pyramid should get a failed test result on its tests tab. The
>> > problem is that this does increase the load on the test system
greatly,
>> > but perhaps we can get enough hardware to make that OK. Not sure.
>>
>>
>> Having this sort of CI would be awesome, however it looks like it's not
on the
>> top of the TODO list:
>>
>> RFE: Koschei-like CI (opened 8 months ago)
>>
https://pagure.io/fedora-ci/general/issue/45
>>
>> RFE: Check if dependent packages install (opened 8 months ago)
>>
https://pagure.io/fedora-ci/general/issue/46
>>
>> Support automatic execution of tests of dependent components (opened 1 year
ago)
>>
https://pagure.io/fedora-ci/general/issue/7
>>
>>
>> And either way, since CI is opt-in, I would need to go and setup CI for all
of
>> dependencies (including transitive) of all my packages. I haven't
really
>> checked
>> how big is this tree but I suppose it is enormous.
>>
>>
>> Would an automated daily report (like the broken rawhide deps report that we
>> used to have) help? I could hack that together for different fedora branches +
>> updates-testing pretty easily, and adding notifications when a broken dependency
>> gets added in -testing wouldn't be hard either.
>
> I've mostl started this thread to see if I indeed need to script this.
>
> If you could look into it, ut would be awesome.
>
> This is very useful as starting point (rawhide example):
>
> $ sudo dnf --repo=rawhide makecache
> $ installcheck x86_64 /var/cache/dnf/rawhide*.solv*
>
> (Igor has shown this to me at Flock.)
>
> It would probably need some interface that let me filter my packages. And
> multi-repo for released Fedora.
>
> This is what we use for Python 2 in rawhide:
>
>
https://github.com/fedora-python/portingdb/blob/master/portingdb/check_ft...
Oh, I didn't know installcheck existed.
I've used repoclosure to get unsatisfied dependencies for all packages
(including unsatisfied BRs).
My initial work is here:
https://pagure.io/fedora-health-check
Looks awesome. Thanks.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok