-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prioritize larger package inspections #5
Comments
One suggestion from @dcantrell was the take the list and sort by size, starting with largest builds first and work down to smaller builds instead of alphabetically like we are now, instead of manually curating a list of "big builds". |
Since you're talking to koji, you should be able to get a build size too, which should be sufficient for sorting. |
I have this working in a basic proof-of-concept in python. I want to merge this (sort by koji build size) into generate_list.py and make it an option you can toggle on/off. |
We should also create a cache file like we have for nvr-to-package.py, as the 2,500+ calls to koji can take upwards of 30+ minutes. After the first run, subsequent re-runs should be much faster. |
I think we make rename nvr-to-package.json to cache.json and use NVR as the key, with sub-keys for things like package, build size, and whatever else we may want to store to speed up calls. |
To avoid losing the proof of concept, I imported the PoC into git: |
Certain packages can take over an hour, even on a fast system (libreoffice is the current use case I can think of, but there a few that aren't quite as bad).
It would be nice to bump these to the top of the list of builds to run on tag-runner, either at generation of the list time or even at runtime regardless of the list order. This would mostly help finish a full tag run faster if we can start chomping on the bigger builds straight away vs the middle or later.
The text was updated successfully, but these errors were encountered: