Hi, I'm happy you like Copr. In the project settings, I can see that you have enabled Old builds will be deleted automatically in Other options. Try to uncheck the box.

Hi @schlupov ,
thanks for the answer.
I tried and looked a lot of times at the "project settings" window but really I cannot see that "Old builds will be deleted automatically" setting (I can see the box "3. Other options" though).

I'm looking at: https://copr.fedorainfracloud.org/coprs/f18m/cmonitor/edit/

Can you see that setting "Old builds will be deleted automatically" there?

Thanks

@f18m hi, see this:
https://docs.pagure.org/copr.copr/user_documentation.html#how-long-do-you-keep-the-builds

The option @schlupov mentions are for a different use case. It implies "persistent"
projects - those where nothing can ever be removed (all the builds stay in project
forever).

I'd encourage you to put the version into the package name (so you
would have several packages, and one build of each - the latest NVR - stays in repo) or provide
several projects (one for each version).

Or if there's any idea about this, please suggest :-)

It implies "persistent"
projects - those where nothing can ever be removed (all the builds stay in project
forever).

Just to elaborate a bit more - this option exists (historically) to mimic what is
done in Koji (all successful builds stay available - just to be sure
that any potential change to the repository is reproducible, and that
anyone can observe all the build logs for builds that ever could have any
effect on the final dnf repo, even if the builds are already obsoleted by
a newer NVR).

In Copr, we pay attention to remove stuff that's not necessarily needed,
because with the frequency of all the builds we would run out of storage
very quickly.

@f18m hi, see this:
https://docs.pagure.org/copr.copr/user_documentation.html#how-long-do-you-keep-the-builds

The option @schlupov mentions are for a different use case. It implies "persistent"
projects - those where nothing can ever be removed (all the builds stay in project
forever).

I'd encourage you to put the version into the package name (so you
would have several packages, and one build of each - the latest NVR - stays in repo) or provide
several projects (one for each version).

Thanks for the suggestion. I didn't realize I could do that.
Maybe this would be nice to mention at this page: https://docs.pagure.org/copr.copr/user_documentation.html#how-long-do-you-keep-the-builds

Or even having a "Cleanup policy" chapter in the "User documentation" (https://docs.pagure.org/copr.copr/user_documentation.html) would make it easier to find this topic. I think it's pretty important the retention aspect and not knowing the cleanup policies can disrupt CI/CDs and cause all sort of troubles...

Or if there's any idea about this, please suggest :-)

I suggest consider a feature like the Teamcity's "pinned builds", see https://www.jetbrains.com/help/teamcity/pinned-build.html .
This would be a manual step done by the developer (so unlikely to happen massively on lots of builds!) to declare that a build is important...

thanks!

We can document that, I think.

The "pinned" build sounds OK to me as well (from the user perspective),
though it is not going to be an easy thing for implementation.

Hi @praiskup ,
Sorry to bother you but my problem (RPMs cleaned up) apperead toady after 14 days since my last attempt to fix it.

I followed your suggestion:

I'd encourage you to put the version into the package name (so you
would have several packages, and one build of each - the latest NVR - stays in repo) or provide
several projects (one for each version).

You can see that here:

https://copr.fedorainfracloud.org/coprs/f18m/cmonitor/packages/

But still from today the version 2.3.0-0 of package "cmonitor-collector-2.3.0" (and the same for the "tools" variant) is not available anymore.
Now yum/dnf client is able to find only the very latest release, which is 2.3.1.

Can you help me understand what's going on?

thanks

Can you help me understand what's going on?

Sure. Just changing the spec file, or the package name in Copr isn't enough.

See e.g. this:
https://copr-dist-git.fedorainfracloud.org/cgit/f18m/cmonitor/cmonitor-collector-2.3.0.git/commit/?id=d001da18451ee7c0d5919743033dbb6f2b62ad41

+Name:           cmonitor-collector
+Version:        2.3.0

The "2.3.0" version needs to be part of the Name feld, not Version. What is usually
done by Fedora packagers is to use Name: cmonitor-collector230 or ..._2_3_0.

DNF (and /bin/prunerepo utility) doesn't see anything other than name/version/release
provided by the built package.

Hi @praiskup ,
thanks for the answer.
Now I understand better what you mean... that solution however requires me to create a new .spec file every time I want to "pin" a specific version of the project.
Moreover it also changes the user experience. Instead of running "dnf install cmonitor-tools-X.Y.Z" they would need to run "dnf install cmonitor-tools_X_Y_Z" or similar, and commands like "dnf search --showduplicate cmonitor-tools" would not return multiple versions of the same package, just multiple packages.

This looks like a trouble for maintainance and to explain to users.
Another possibility would be to setup a cronjob that invokes the rest API to trigger rebuild of all my packages every 13 days or so.
But I hope that in the future COPR will gain the ability to "pin" a build (maybe just by REST API, without any UI)...

thanks for the help!

This issue has been migrated to GitHub: https://github.com/fedora-copr/copr/issues/2050