Dne 20. 04. 20 v 13:52 Ondrej Nosek napsal(a): > > > On Mon, Apr 20, 2020 at 11:42 AM Vít Ondruch <vondr...@redhat.com > <mailto:vondr...@redhat.com>> wrote: > > > Dne 20. 04. 20 v 1:31 Ondrej Nosek napsal(a): >> Thanks for answers, comment in the text follows. >> >> On Tue, Apr 14, 2020 at 12:16 PM clime <cl...@fedoraproject.org >> <mailto:cl...@fedoraproject.org>> wrote: >> >> On Tue, 14 Apr 2020 at 12:05, Vít Ondruch >> <vondr...@redhat.com <mailto:vondr...@redhat.com>> wrote: >> > >> > >> > Dne 14. 04. 20 v 0:13 Ondrej Nosek napsal(a): >> > >> > TLDR: Is $SUBJ function reasonable to implement in fedpkg? >> > >> > Hi, >> > >> > some time ago, fedpkg issue tracker got a request [1] for >> method, that allows direct builds. That means without sending >> srpms via "--srpm" argument. Currently, user's changes can be >> built: >> > >> > fedpkg scratch-build --srpm >> > >> > This way, fedpkg sends srpm file to koji. Without "--srpm", >> fedpkg sends just (git) hash id to koji. But fedpkg needs >> modification to send a right hash id for user changes. >> Additionally, koji doesn't allow building hash ids from >> forked repos. >> > >> > >> > Even if this was possible, that would also mean that the >> sources have to be uploaded into look-a-side cache. Then it >> very much depend what is the content of the PR. If I am >> building Ruby nightly snapshots, I don't think it is fair to >> pollute look-a-side cache with them and I am afraid this is >> not the only case. I wish we had a way to override the >> look-a-side cache somehow .... >> >> If I understand correctly, this would have to be done, if sources >> changed only, right? I.e. if there is a change just in patch >> or a spec >> file, the sources could be fetched from the main project. >> >> >> Yes, just sources (and eventually other binary files) are >> uploaded to lookaside cache. In the case of specfile and patches, >> there is no lookaside modification. Fork shares the same >> lookaside cache with the main project. >> >> >> >> Should there be a possibility to upload sources for a fork >> that would >> then be moved to the main project when the pull request is >> merged? >> >> >> That sounds complicated to me and maybe it is not worth the >> intended result. Or I didn't find the right (easier) approach. >> ... New sources (and binaries) in fork need to be saved somewhere. >> - In a parallel lookaside (for forks) >> - In git repo (omitting lookaside) >> During the merge, some trigger would move the sources to the main >> lookaside. This creates a new file hash(es). And it would result >> in another commit done by a trigger. > > > Why it should create new hash(es)? If the fork/PR contains an > updated sources file (and it really should), then there is no > reason for new commit. > > > Oh. In my last post, I wanted to say, that no commit is needed if you > are using main lookaside. Just in case you have parallel lookaside or > other storage, you have to upload sources from your alternative > storage to main lookaside and it would result in the extra commit. > But I looked at code how lookaside works internally. Hash is computed > locally and the upload path (except the host) should be the same for > both lookasides. So I realized that during merge, only download the > sources from parallel lookaside and upload it to the main lookaside > would work. Without extra commit. But is it a win? This might bring > other problems. Timeouts when some large source is processed? > Parallel lookaside is intended to not mess the main lookaside. So I > think the parallel lookaside should be cleaned somehow.
It should be cleaned as often as the stalled PRs? I know we don't have infrastructure for this, but it would be logical answer to your question. Vít
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
