On 07. 11. 19 9:55, Fabio Valentini wrote:
On Thu, Nov 7, 2019, 09:25 Miro Hrončok <mhroncok@xxxxxxxxxx
<mailto:mhroncok@xxxxxxxxxx>> 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_fti.py
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
