#840 Option to only include the latest successful build in the repos
Closed: MIGRATED a year ago by nikromen. Opened 4 years ago by churchyard.

I'd like to request an opt-in option to only include the latest successful build in the repos.

Currently, all (not yet garbage collected) successful builds are included in the repositories. Making the metadata needlessly large and the createrepo needlessly time consuming.

Thanks for considering.


We already do this, but we clean the builds once they are at least 14 days old (the old succeeded builds (older NVR) are removed without asking).

Plus slightly related work-around nowadays is also to setup each package with --max-builds option ... so you'll have at most N builds of each package (though both failed and succeeded). If set, your builds would be removed overnight.

Otherwise seems like valid RFE.

Metadata Update from @praiskup:
- Issue tagged with: RFE

4 years ago

As a side note, it would be nice to prioritize builds with higher IDs if the NEVRs are equal.

Imagine I build python-foo-1-1 in the repo (against Python 3.8.0b1).
Later I build python-foo-1-1 in the repo again (against Python 3.8.0b2), for lezyness, I don't bump the release.

The older build is in the generated repo until I manually delete it. Then the newer one gets in. With the "latest builds only" I'd expect the newer build to be in the repos.

This rpmdev-bumpspec laziness would trigger all sort of undefined behavior in dnf/rpm/createrepo_c/etc.etc stack ... so I doubt it is worth having some additional logic on copr side.

if you really want to make something about it, I'd suggest you to fill a ticket against prunerepo project (copr uses that to cleanup older succeeded build results), ... so prunerepo could take the mtime into account. Prunerepo though knows nothing about build id.

Note that if you setup --max-builds option per package, the build-id is actually respected (not nevra) -- and copr will remove only builds which have the oldest build id for you.

As well createrepo_c could (theoretically) prefer newer files (when multiple RPMs have the same nevera) when generating repos.

yet max-builds would happily clean a successful build just to keep a failed one, correct?

+1 to this RFE. I can't think of any good use case for the current max-builds, because nobody wants to delete a successful build to hold a failure. It could be of some usage if there is a --max-successful-builds. Consider this:

--max-successful-builds 1 --max-builds 2

This means that I want just 1 successful build, but I want to keep 1 failure (e.g., to inspect what happened).

Sorry but I don't see how. This is a RFE for "only keep the latest successful build" while the linke commit is a solution for the "lazy to bump" problem, but not applicable to our case (because we build from Fedora sources and those don't have %buildtag in Release).

Metadata Update from @churchyard:
- Issue status updated to: Open (was: Closed)

3 years ago

Metadata Update from @praiskup:
- Issue assigned to praiskup

2 years ago

This is being revamped after the Nest 2022 chat. Fix in createrepo_c could help:
https://github.com/rpm-software-management/createrepo_c/pull/325

Metadata Update from @nikromen:
- Issue close_status updated to: MIGRATED
- Issue status updated to: Closed (was: Open)

a year ago

Login to comment on this ticket.

Metadata
Related Pull Requests
  • #1436 Merged 3 years ago