On středa 17. července 2024 11:21:15, SELČ David Bold wrote:
> Adam Samalik wrote:
> > On Wed, 17 Jul 2024 at 10:54, Pavel Raiskup praiskup@xxxxxxxxxx wrote:
> > > On úterý 16. července 2024 15:22:56, SELČ Stephen Gallagher wrote:
> > > On Tue, Jul 16, 2024 at 3:44 AM Pavel Raiskup praiskup@xxxxxxxxxx
> > > wrote:
> > > > [snip]
> > > > > Do you suggest moving rawhide to branched, and start with a fresh
> > > > > (empty)
> > > > > rawhide chroots for every branching?
> > > >
> > > > Yes, that was exactly what I was suggesting. (Well, possibly with
> > > > auto-triggering builds for the new chroot if the option to follow
> > > > Fedora branching is enabled).
> > >
> > > Starting from scratch would definitely be an alternative option (WRT to
> > > storage consumption), even more radical though. Some of the projects in
> > > Copr require non-trivial bootstrapping procedures (not as complicated as
> > > Fedora itself, but still).
> >
> > What if you copied the latest build for each package to the "new"
> > rawhide chroot? That way all the builds should be able to continue
> > without bootstrapping as they do now, without having to store the
> > entire build history.
>
> But that would still keep those builds forever.
It would, indeed. But wouldn't this be 100% equivalent to what we
already have? Currently, when F41 branches from Rawhide, we do:
mkdir fedora-41-x86_64
ln fedora-rawhide-x86_64/foo.rpm fedora-41-x86_64/foo.rpm
...
createrepo_c fedora-rawhide-x86_64
... now we could rebuild the packages in rawhide, but not implemented ...
We _do not_ "branch" (link) all the RPMs in the repository, just the
latest versions (optimization from the time when we did `cp` instead of
`ln`, nowadays we could simply link everything I think).
What is proposed here is:
mv fedora-rawhide-x86_64 fedora-41-x86_64 # we need to avoid the race here!
mkdir fedora-rawhide-x86_64
cp fedora-41-x86_64/foo.rpm fedora-rawhide-x86_64
createrepo_c fedora-rawhide-x86_64
... now we could rebuild the packages as well ...
> Besides that, the branching would create additional chroots in the
> project. I have a copr project that I only use for test builds, and I
> do not want additional chroots.
There's an opt-out knob for this feature, "follow fedora branching"
> Automatic branching would at some point either delete all my build,
> which is both annoying if I want to test multi-package changes as well
> as single package debugging, as in this case I cannot look at the
> build log of an hour ago.
We link all the files in the result directory, including log files. On
top of that, you get the "forked" chroot build entry in web-UI, so
should be fine.
> I would like to have the options to delete all builds automatically
> after a month, instead I have to manually delete them.
Copr anyway keeps just the latest-greatesr NVR, so it's not a storage
concern itself. I assume you are tired of seeing countless build
records in the web-UI - if so, please submit an RFE, or ideally send
us a patch!
> As far as I could see there is only an option to automatically delete
> the whole project, but not to delete builds after a given time.
Indeed. Plus, per-package, you can set the max number of builds that
are being kept.
Pavel
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
