Learn more about these different git repos.
Other Git URLs
Old builds are supposed to be removed automatically after 7 days if I'm not mistaken. Apparently, this is not happening, though. Example: R-CRAN-proj4. The newest successful build, 1036358, is from 15 days ago already, but 1029981, from 27 days ago, is still there. However, the results folders were removed, e.g., fedora-30-x86_64.
Thanks for the report, but this looks like false alarm.
The package has two builds, 1036358 and 1029981 [1]. For the cleanup script (prunerepo), the build ID is not relevant - only package's NVR is compared and the highest NVR is kept.
In your case though there's no surprise, both the NVR and build ID are newer in 1036358. And also the build results are there.
[1] https://copr.fedorainfracloud.org/coprs/iucar/cran/package/R-CRAN-proj4/
Metadata Update from @praiskup: - Issue close_status updated to: Invalid - Issue status updated to: Closed (was: Open)
https://docs.pagure.org/copr.copr/user_documentation.html#how-long-do-you-keep-the-builds
But please substitute 14 with 7. We need to adjust the docs.
Well, that's the point: if NVR is newer in 1036358, shouldn't 1029981 be removed already?
It is removed, you only see the database entry - but backend doesn't provide the packages.
Ok, understood: so keeping the database entry is a feature, not a bug. :) And what's the point of keeping this?
Keeping the database is not really a feature. The feature is to cleanup the yum repository no matter what is in frontend's database; it happens solely on backend now..
Yes, it would be nice to let frontend know and update the database (either to remove the buildchroots or rather mark them as deleted). But it wouldn't be trivial to implement, and RFE like that would have very low priority. Patches are welcome of course.
Login to comment on this ticket.