DEFAULT_MAX_KEEP_RPMS should be configurable

[jvale]

The current DEFAULT_MAX_KEEP_RPMS is 1, which can be problematic and can lead to RPMs being cleaned up accidentally.

This value should be overridable in the configuration.

[mriehl]

What do you mean with problematic?

An important repo where nobody thinks about increasing the number of kept RPMs (thus the default of 1) where a new version erases an older one that cannot be rebuilt?

IMHO the default of keeping only the newest version is almost always what you want (except for production repos where you want the ability to downgrade). Things that kinda work usually don't get customized so you'd have more useless rpms in storage (probably). Since the actual setting can be tuned on a per-repo basis I think it's fair game to default to 1.

But anyway it's not hard to add. If you want to tradeoff disk space for reduced risk then power to you!

[jvale]

(Wow I am lagged...)

In a use-case where you have continuous integration but you don't deploy directly to production every single build, the generated RPMs may sit in the repo for a few builds until it gets pushed to prod. In this case, the desired RPM will be overwritten before it gets a chance to see the light of day.

If it's not something that interests you directly I can look into adding support for it if and when I get some free time.

[schlomo]

@jvale thank you for clarifying your use case. Could you submit a pull request?